Method and system to authenticate multiple IMS identities

ABSTRACT

A method and UE for registering with a third network node using IMS, the method creating a tunnel; authenticating a first public identity associated with the UE to the first network node; receiving configuration information with a second private identifier and a second public user identifier, and registering with a third network node using the second private identifier and the second public user identifier. Further, a method and first network node configured for authentication between a UE and a third network node using IMS, the method establishing a tunnel; authenticating a first public identity of the UE; receiving a configuration information message from the UE including a network identifier for a network the UE is registered on; obtaining, from a second network node, a second private identifier and second public user identifier; and providing the second private identifier and second public user identifier to the UE.

This patent is a continuation of U.S. Non-Provisional application Ser.No. 14/788,099, filed Jun. 30, 2015, the entire contents of which ishereby expressly incorporated by reference herein in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to an internet protocol (IP) multimediasubsystem (IMS), and in particular relates to the validation ofidentities in an IMS network.

BACKGROUND

The IP multimedia subsystem is an architectural framework for providingpacket data to mobile devices in a standardized fashion. Such IMSnetwork allows for voice calls over a packet system rather the circuitswitched system. It allows for other functionalities such as push totalk (PTT), and in particular, mission critical push to talk (MCPTT)used for first responders.

IMS authentication authenticates both a private identifier and a publicidentifier for use on the IMS network. However, the IMS authenticationdoes not allow different individual IMS public user identities to beseparately authenticated with the same or different IMS private useridentities. This can lead to problems in various situations. Forexample, if used by first responders, a MCPTT application may need adevice to be authenticated by a different public identity than that tiedto the private identity of the device.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be better understood with reference to thedrawings, in which:

FIG. 1 is a block diagram of an example IMS network;

FIG. 2 is a data flow diagram showing authentication of anIM-subscriber;

FIG. 3 is a block diagram showing an association between private andpublic user identities in an IMS system;

FIG. 4 is a block diagram showing signaling between a public safetyoperator and a public safety UE, including various network elements;

FIG. 5A is a block diagram of a protocol stack for EAP authentication;

FIG. 5B is a block diagram of a protocol stack when the EAP is the userauthentication protocol;

FIG. 6 is a data flow diagram showing a first in band embodimentproviding an indication for double authentication;

FIG. 7 is a data flow diagram for an alternative in band embodiment inwhich a second public user identity is used in authentication;

FIG. 8 is a data flow diagram of an in band embodiment showing keyingbased on public user identifiers;

FIG. 9 is a block diagram showing a process for key generation in an HSSand a UE;

FIG. 10 is a block diagram of a key generation process at a networkelement in which a public user PIN is obscured from a carrier;

FIG. 11 is a block diagram of a key generation process at a userequipment in which a public user PIN is obscured from a carrier;

FIG. 12 is a data flow diagram showing an out of band embodiment for IMSauthentication;

FIG. 13 is a block diagram showing an out of band authenticationprocess;

FIG. 14 is a data flow diagram showing an out of band embodimentutilizing different public user identities for authentication;

FIG. 15 is a data flow diagram shown an out of band embodiment in whicha UE can roam into a second MCPTT network;

FIG. 16 is a block diagram showing an example data structure for MCPTTdata;

FIG. 17 is a data flow diagram showing authentication utilizingcertificates;

FIG. 18 is a block diagram showing the generation of a certificate;

FIG. 19 is a simplified block diagram of an example network element; and

FIG. 20 is a block diagram of an example user equipment for use with theembodiments of the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

The present disclosure provides a method at a user equipment forregistering with a third network node using an internet protocol (IP)multimedia subsystem (IMS), the method comprising: creating a tunnelbetween the user equipment and a first network node; authenticating afirst public identity associated with the user equipment to the firstnetwork node; receiving configuration information from the first networknode with a second private user identifier and a second public useridentifier, the second private user identifier and second public useridentifier being associated with a second network node; and registeringwith a third network node using the second private user identifier andthe second public user identifier.

The present disclosure further provides a user equipment configured forregistering with a third network node using an internet protocol (IP)multimedia subsystem (IMS), the user equipment comprising: a processor;and a communications subsystem, wherein the user equipment is configuredto: create a tunnel between the user equipment and a first network node;authenticate a first public identity associated with the user equipmentto the first network node; receive configuration information from thefirst network node with a second private user identifier and a secondpublic user identifier, the second private user identifier and secondpublic user identifier being associated with a second network node; andregister with a third network node using the second private useridentifier and the second public user identifier.

The present disclosure further provides a method at first network nodeconfigured for authentication between a user equipment and a thirdnetwork node using an internet protocol (IP) multimedia subsystem (IMS),the method comprising: establishing a tunnel with the user equipment;authenticating a first public identity of the user equipment at firstnetwork node; receiving a configuration information message from theuser equipment, the configuration information message including anetwork identifier for a network the user equipment is registered on;obtaining, from a second network node, a second private user identifierand second public user identifier; and providing the second private useridentifier and second public user identifier to the user equipment.

The present disclosure further provides a first network node configuredfor authentication between a user equipment and a third network nodeusing an internet protocol (IP) multimedia subsystem (IMS) the firstnetwork node comprising: a processor; and a communications subsystem,wherein the first network node is configured to: establish a tunnel withthe user equipment; authenticate a first public identity of the userequipment at first network node; receive a configuration informationmessage from the user equipment, the configuration information messageincluding a network identifier for a network the user equipment isregistered on; obtain, from a second network node, a second private useridentifier and second public user identifier; and provide the secondprivate user identifier and second public user identifier to the userequipment.

The present disclosure relates generally to authentication in IMSsystems. In one aspect of such authentication, the use of the IMS systemwith regard to MCPTT is discussed below. However, this is not the onlyuse of the IMS network and IMS authentication could equally be used forseparate or different applications. The use of MCPTT below is thereforemeant to be illustrative only.

One example of a deficiency of IMS authentication is illustrated withregard to MCPTT. MCPTT is utilized, for example, by first responders,and has various requirements. These may include, but are not limited to,that any user should be able to pick up any device and use it. Thus, ifa fire station has a number of devices that are not individuallyassigned, but are provided to users on an as needed basis, anyfirefighter should be able to pick up any of the devices that areavailable and utilize such device.

MCPTT may further require that authentication of the MCPTT applicationon a device needs to be independent of the cellular/IMS network in orderto meet security requirements of the public safety service provider andpublic safety users.

In a third aspect, MCPTT may need to be capable of hiding or obscuringthe identity or role of a user who is using the device. For example, inthe case where the first responder is a police officer, in somesituations it may be desirable to protect the confidentiality of theidentity of that police officer when using the MCPTT application. Theobscuring may need to include obscuring a true public identity from acarrier or network operator.

Given the three aspects described above, and the way that IMSauthentication works as described below, IMS authentication does notprovide for compatible functionality with MCPTT. Specifically, thecurrent IMS method of authentication is based on an IMS private useridentity, and does not allow for different individual IMS public useridentities to be separately authenticated with the same or different IMSprivate user identity. Thus, for example, if a first user and a seconduser use the same mobile device in a non-concurrent way, then the systemis unable to differentiate who the user is and hence unable toauthenticate the two users differently and is incapable of denying oneaccess while granting the other access. Thus the present disclosureprovides for a method and system for authenticating both the device andthe user and then providing for a determination if a user should beallowed to use the device or not.

As used herein, the terms private identifier and private user identifiermay be used interchangeably.

In accordance with the disclosure below, various solutions to the aboveproblem are provided. In particular, the present disclosure describesvarious in band solutions, which utilize current IMS authenticationmessaging to piggy back a separate public identity verification. Othersolutions described below include out of band solutions which providefor the verification of a public identity utilizing messaging outside ofregular IMS authentication. Further, various keying based on a publicuser identity are provided which may be used in either the in band orout of band signaling solutions described below. One skilled in the artwill appreciate that these in band, out of band and keying based onpublic user identity can be combined in numerous ways to result inadditional embodiments.

In one aspect of the embodiments described below, the user identity of aparticular user may be obscured in a system, and various solutions areprovided for the obscuring of a public identity.

Reference is now made to FIG. 1, which shows an overview of an exampleIMS network attached to a 4th Generation (4G) network. The example ofFIG. 1 is merely meant to illustrate various components within a networkarchitecture. The embodiment of FIG. 1 is not limiting and real networkswill have some or all of the components, along with additionalcomponents, in most cases.

Further, as described below, each of the elements may be considered tobe a logical block. That is, the functionality of elements may becombined onto one server. Further, the functionality of a single elementmay be split over multiple physical servers and the present disclosureis not limited to the use of any particular physical architecture.

In the example of FIG. 1, a 4^(th) Generation (4G) network 110 mayutilize an IMS network 130 to provide for standardized packet datacommunications. In particular, 4G network 110 may be a third generation(3G) long term evolution (LTE) or system architecture evolution (SAE)network in which a device 112 or a device 114 may communicate. Devices112 and 114 may be any device that is capable of communicating over acellular network, and may include, for example, a user equipment (UE), amobile device, a smartphone, a laptop, a tablet, or any other datacapable device.

Device 112 communicates through an evolved Node-B (eNB) 116 utilizingorthogonal frequency division multiplexing (OFDM), communication over anLTE-Uu interface.

Similarly, device 114 communications with eNB 118 over an LTE-Uuinterface.

Each of eNBs 116 and 118 communicate with two entities, namely servinggateway 120 and mobility management entity (MME) 122. MME 122 isresponsible for idle mode UEs paging and is also responsible forchoosing a serving gateway 120 when a UE moves into a connected mode.

Serving gateway 120 routes and forwards packets from devices 112 and114.

The serving gateway 120 communicates with SAE anchor 124. SAE anchor 124is a functional entity that anchors the user plane for mobility betweenthe 3^(rd) Generation Partnership Project (3GPP) access stratum andnon-3GPP access stratum for systems such as the Institute for Electricaland Electronics Engineers (IEEE) 802.11 (Wi-Fi), among other non-3GPPaccess systems.

MME 122 communicates with a 3GPP anchor 126. 3GPP anchor 126 is afunctional entity that anchors the user plane for mobility betweensecond generation and third generation access stratum and the LTE accesssystem.

IMS network 130 may communicate with 4G network 110 through variouslogical entities. In a first aspect, MME 122 may communicate with a homesubscriber server (HSS) 132. HSS 132 is a database that contains thesubscriber's profile including identities and what services they havesubscribed to, and that provides location functionality as well as anauthentication database.

MME 122 may also communicate with the policy and charging rules function(PCRF) server 134. The PCRF 134 is an element within the IMS networkthat controls both the policies of subscribers as well as the amountscharged to such subscribers.

The PCRF 134 and the HSS 132, as well as 3GPP anchor 126, maycommunicate with the call server control function (CSCF) 136 of IMSnetwork 130. CSCF 136 provides several session initiation protocol (SIP)servers or proxies that are used to process SIP signaling packets in theIMS network 130.

In particular, CSCF 136 may include various logical entities including aproxy call session control function (P-CSCF), which is the first pointof entry into the IMS network. Further, a serving call session controlfunction (S-CSCF) handles sessions in the network and routes SIPmessages to appropriate P-CSCFs as well as IMS application servers (IMSAS). Further, CSCF 136 may include an interrogating call session controlfunction (I-CSCF) that is used as an entry point to find a subscriber inthe network and assist in assigning an S-CSCF when a subscriberregisters in the network.

IMS application server (AS) 138 is an application server that has thelogic and software which executes services for an IMS subscriber. IMSnetwork 130 may have between 0 and many of these IMS AS 138 in thenetwork. CSCF 136 may provide output to voice-over IP services (VOIP),as shown in the example of FIG. 1.

CSCF 136 may further communicate with a media resource function (MRF)140, which provides media related functions such as media manipulation.MRF 140 may further be connected to a media server 142.

CSCF 136 may be connected with a breakout gateway control function(BGCF) 144, which allows for the processing of SIP requests from anS-CSCF when domain name server (DNS) routing cannot be used.

Both CSCF 136 and BGCF 144 may communicate with a media gateway controlfunction (MGCF) 146, which is in communication with an IMS media gateway(IMS MG) 148 to allow access to a circuit switched domain.

Further, MGCF 146 may communicate with a signaling gateway (SG) 150,which may also allow for communications with a circuit switched domain.

In certain circumstances, besides a 4G network 110, a 3G network or 3.5Gnetwork 160 may be utilized. In this case, devices 162 or 164 maycommunicate with node-B 166 and node-B 168 respectively, utilizing highspeed packet access (HSPA) over a Uu interface.

Both node-Bs 166 and 168 communicate with a radio network control (RNC)170, which controls the node-Bs that are connected to RNC 170.

RNC 170 communicates with a serving general packet radio service (GPRS)support node (SGSN) 172, which is responsible for delivering packets toand from mobile stations that are in the geographical location of theSGSN 172. RNC 170 further communicates with mobile switching center(MSC) 174 which controls network switching elements.

SGSN 172 may be connected to a gateway GPRS support node (GGSN) 176.SGSN 172 further communicates with MME 122 and with serving gateway 120in a 4G network for transferring devices between the 4G and the 3Gnetworks.

GGSN 176 may further utilize the IMS network 130 through CSCF 136.

In the embodiment of FIG. 1, a femtocell 180 is further provided. Inthis example, a device 182 communicates with a femtocell access point184 over a high speed packet access link.

Femtocell 180 may include a security gateway 186 as well as afemtogateway 188. Femtogateway 188 may then communicate with SGSN 172and MSC 174 in 3G network 160.

As indicated above, FIG. 1 is meant to merely show elements of thecommunications utilizing an IMS network 130 and other examples andnetwork architectures are therefore possible.

IMS Authentication

As indicated above, a device such as device 112, 114, 162, 164 or 180from FIG. 1 above, may wish to authenticate with the IMS network 130.Currently, authentication includes first registering with the network.The IMS registration is independent of the underlying access network,allowing for access agnostic services to be standardized.

When the user registers with the network, a security association iscreated between the network and the IMS device. This allows the user touse an IMS service that they have subscribed to, and to also protectdata by setting up an internet protocol security (IPSec) tunnel betweenthe device and the P-CSCF.

As described below, an IMS device will be referred to as a SIP UserAgent (UA). However, this is not limiting and any device could beutilized.

A SIP UA is a logical entity that implements the client SIPfunctionality. Some implementations of the SIP UA can be wireless orfixed, such as but not limited to set-top boxes, laptops, desktops etc.The SIP UA provides two identities to the network. A first is a privateIMS identity, known as the IMS private identity (IMPI) and the other isknown as the public user identity, referred to as the IMS publicidentity (IMPU).

The public identity is the identity that may be used to contact theuser. The IMPI is the identity which is used to authenticate the SIP UAand grant access to the IMS system. The IMPI is stored in the HSS 132 inthe home operator's network, and may be derived from the internationalsubscriber identity (IMSI) stored on the universal subscriber identitymodule (USIM) or may be stored in the IMS subscriber identity module(ISIM).

The above is described, for example, in the Third Generation PartnershipProject (3GPP) Technical Specification (TS) 33.203, “3G security; Accesssecurity for IP-based services”, v.12.8.0, December 2012, the contentsof which are incorporated herein by reference.

Section 6.1 of this technical standard deals with the authentication andkey agreement (AKA). In particular, as described in Section 6.1.0, theIMS AKA achieves mutual authentication between the ISIM if present, elsethe USIM, and the home network (HN). The identity used forauthenticating a subscriber is the private identity, IMPI, which has theform of a network access identifier (NAI), as described, for example in3GPP TS 23.228 which is in a format as described in RFC 4282. The HSSand the ISIM/USIM share a long-term key associated with the IMPI.

Further, as described in Section 6.1.1 of the 3GPP TS 33.203specification, before a user can get access to the IM services at leastone IMPU needs to be registered and the IMPI authenticated in the IMS atan application level. The IMPI is also therefore used to identify theHSS where the subscription profile is stored.

Both the IMPI and the IMPU can be changed on the USIM/ISIM using OverThe Air (OTA) functionality. This OTA functionality allows an operatorto change data items on ISIM/USIM.

If the hardware associated with the SIP UA functionality is used toaccess a 3GPP system, there will also be a universal integrated circuitcard (UICC). The UICC contains applications such as a USIM applicationand possibly an ISIM application. The USIM and ISIM applications containidentities and authentication algorithms to access the 3GPP network.

The USIM contains the IMSI and the authentication mechanism, which iscalled 3GPP AKA. The ISIM contains the private identity in the form of ausername@domain and the public user identity is also in same form. TheISIM also contains an authentication mechanism called IMS AKA, but theoutput of the algorithm is different.

Authentication of a SIP UA is therefore performed using the IMPI. TheIMPI used for authentication can be likened to that of the IMSI and canbe either obtained from the ISIM Private Identity; or derived from theUSIM IMSI if the ISIM is not present or does not have an IMPI stored onit.

The IMPI along with an IMPU, is sent in a SIP REGISTRATION message tothe network. The network, based on the IMPI used in conjunction with theAKA mechanism, will send back a number of authentication vectors. Theseare, for example, described in 3GPP TS 33.203 in Section 6.1.1.

Reference is now made to FIG. 2. In particular, as seen in FIG. 2, theUE 210 sends a SIP registration message 230 to the P-CSCF 212. The SIPregistration message is then forwarded to the I-CSCF 214 as message 232.I-CSCF 214 then chooses the HSS 216 and the S-CSCF 218 for theregistration message, as shown by block 234 and message 236.

A challenge is then sent back to the UE and the registration occursbased on the challenge. In particular, the S-CSCF performs a PUT withHSS 216, as shown by block 240, and then sends an AV-request to HSS 216,shown by message 242. An AV-request-response 244 is received from HSS216 at S-CSCF 218.

S-CSCF 218 then sends the authentication challenge to I-CSCF 214 inmessage 250. The authentication challenge is forwarded to P-CSCF 212 inmessage 252 and then to UE 210 in message 254.

The response to the challenge is in the form of a vector with regard tothe IMSI and the response is then sent back to the HSS and S-CSCF whichmay then confirm whether or not the authentication is okay.Specifically, the response is register message 260, which is sent fromUE 210 to P-CSCF 212. The response is then forwarded in message 262 toI-CSCF 214. I-CSCF 214 performs a Cx-Query, shown by block 264, with HSS216, and then forwards the response to S-CSCF 218 as shown by message266.

S-SCSF 218 then verifies the response with HSS 216, shown with Cx-Putblock 270 and Cx-Pull block 272. If the authentication is successful, asuccess message 280 is sent from S-CSCF 218 to I-CSCF 214. The successmessage is then forwarded as message 282 to P-CSCF 212, and as message284 to UE 210.

The IMS also allows more than one public user identity to be associatedwith the private user identity. In fact the public user identity can beassociated with many private user identities as shown, for example, withregard to FIG. 3.

FIG. 3 is a reproduction of FIG. 4.6 of 3GPP TS 23.228, “IP MultimediaSubsystem (IMS); Stage 2”, v.13.2.0, March 2015, the contents of whichare incorporated here by reference. In particular, as seen as in FIG. 3,an IMS subscription 310 includes two private user identities 320 and330. Private user identity 320 includes two public user identities,namely public user identity 322 and 324.

Private user identity 330 further includes public user identity 324 aswell as public user identity 332.

Public user identity 322 is associated with a service profile 340 andpublic user identity 324 and public user identity 332 share a serviceprofile 342.

Thus, as seen in FIG. 3, the IMS subscription may have various privateuser identities and public user identities that are associated with oneor more of the private user identities.

There is no authentication associated with public user identities 322,324 or 332. Policing of what user identity can be used by the UE isperformed by the HSS downloading via S-CSCF into the P-CSCF the publicuser identities that can be used by the device. When the deviceoriginates a session, the P-CSCF will ensure only valid public useridentities are used.

When the IMPU is registered with the IMS network, the HSS will downloadto the S-CSCF a service profile. Service profile such as service profile340 or 342 from FIG. 3, describe under what circumstances the IMSapplication servers should be involved in a call/session. For example,the servers may be involved in the execution of services associated withthe public user identity and will be controlled by the S-CSCF.

As identified above, the IMS authentication mechanism is called IMS AKA.IMS also allows for other authentication schemes to be supportedincluding, but not limited to, SIP Digest, Transport Layer Security(TLS), GPRS-IMS-Bundled Authentication (GIBA). Network Access Subsystem(NASS)-IMS bundled authentication is also allowed to be used forauthentication from either a fixed specific location or for early IMSdeployments where IMS AKA is not available. GPRS IMS BundledAuthentication is another variant of NASS-IMS bundled, and is used forearly IMS deployments. Such authentication schemes are, for example,described in 3GPP TS 33.203 in Sections N.1, O.1.1, R.1, and T.1.

However, there is no way to verify the public user identity. Thispresents issues in certain applications. For example, one applicationthat this may present an issue with is mission critical push to talk(MCPTT), which is described below.

Mission Critical Push to Talk

Mission critical push to talk is a push to talk service used for missioncritical type operations such as emergency services. However, it mayalso extend to commercial users including utilities, taxi cabs, amongothers. In some cases, MCPTT may be used anywhere that private mobileradio (PMR) systems are present today.

The MCPTT 3GPP service is described in 3GPP TS 22.179, “Mission CriticalPush to Talk (MCPTT) over LTE; Stage 1”, v. 13.1.0, March 2015, thecontents of which are incorporated herein by reference.

As described in Section 4.5 of this specification:

-   -   The MCPTT Service supports MCPTT User Profiles. The MCPTT User        Profile contains important information related to the MCPTT User        receiving the MCPTT Service, including the MCPTT User identity,        which is globally unique and independent of the mobile        subscriber identity (IMSI) assigned by a 3GPP network operator.        Part of the content of the MCPTT User Profile (e.g., containing        some display preferences, some UE audio settings, some address        books) can be set/modified/updated by the MCPTT User, but        significant portions might be set/modified/updated only by        authorized persons. The MCPTT User Profile is stored permanently        in database(s) associated with the infrastructure providing the        MCPTT Service. Relevant parts of the profile might be downloaded        to and cached temporarily or permanently on certain MCPTT Ues.        When stored on an MCPTT UE, the MCPTT User Profile associated        with an MCPTT User might be confidentiality and integrity        protected, with the information available only to a trusted        application client associated to the MCPTT User, upon        authentication. The MCPTT User Profile information can be        synchronized automatically or on demand between the cache on the        MCPTT UE and the main copy held in the database(s) of the MCPTT        Service infrastructure. The MCPTT User Profile is part of the        MCPTT application service domain and forms the basis of MCPTT        application layer security and identifies an MCPTT User to the        MCPTT Service.    -   Each MCPTT User has at least one MCPTT User Profile, and        possibly several. Typically, one of the MCPTT User Profiles is        designated as the default MCPTT User Profile, to be used unless        an MCPTT User Profile is explicitly selected. In general, a user        profile is associated with a specific device, with a specific        mode of operation (i.e., on the network or off the network)        and/or with a specific situation (e.g., user being off-duty, in        a certain city, or playing a certain role). When an MCPTT User        Profile is synchronized between the infrastructure and an MCPTT        device, information could be downloaded to the device and        updated, as necessary. Subsequently and subject to permissions,        the MCPTT User might choose a different associated MCPTT User        Profile to be downloaded and stored on the device. Only one        MCPTT User Profile is active at a time. Authorized users are        allowed to create, delete and alter MCPTT User Profiles for an        MCPTT User and/or pre-stored MCPTT User Profiles.

Further, Section 4.5.1 of the 3GPP TS 22.179 specification indicates:

-   -   Consistent with the EPS paradigm, when an MCPTT UE is powered        on, it accesses the LTE system, and connects to the EPC. During        this phase, the credentials from a USIM application (or        possibly, an ISIM application, if IMS is used) on a UICC        associated with the MCPTT UE is used for authentication with an        HSS. This is followed by the MCPTT Application, resident on the        MCPTT UE, establishing a connection, employing application layer        security in its connection to the MCPTT Service.

Furthermore, as Section 4.5.2. of the 3GPP TS 22.179 specificationstates:

-   -   A user can enter his identifying/authenticating credentials        (e.g., user name/password, PIN, biometrics, asserted identity        from a remote, trusted device). This step typically gives the        MCPTT User access to local information and applications stored        on the MCPTT UE, and in particular, to the MCPTT client        application.    -   The MCPTT Service allows the same MCPTT User to sign in (and        stay simultaneously signed in) from different MCPTT Ues. For        example, an incident manager or commander might use a portable        phone, a command tablet, or a separate messaging unit.

Finally, Section 4.5.4 of this technical specification states:

-   -   The conceptual model for shareable MCPTT Ues is that of a pool        of Ues, each UE being interchangeable with any other, and users        randomly choosing one or more Ues from the pool, each user for        his temporary exclusive use. A shareable MCPTT UE can be used by        user who can gain access to the MCPTT client application stored        on it and can become an authenticated MCPTT User. A shareable        MCPTT UE can serve only one MCPTT User at a time. An MCPTT User        who signs into a shareable MCPTT UE that is already in-use        causes the sign-off of the previous MCPTT User.    -   An MCPTT User can simultaneously have several active MCPTT Ues,        which, from an MCPTT Service point of view, are addressable        individually and/or collectively within the context of their        association to the MCPTT User.

From the above technical specifications, various things may be deduced.One requirement, for example, is that users from a first group could usedevices that belong to a second group. For example, police in France maybe able to use devices that belong to the police in the Netherlands.

One example of MCPTT architecture is provided in 3GPP TS 23.779, “Studyon application architecture to support Mission Critical Push To Talkover LTE (MCPTT) services”, v.0.5.0, February 2015, and is shown, forexample, in FIG. 5.2.1.1.1-1 of that specification, the contents ofwhich are incorporated herein by reference. In particular, public safetyusers may have their own applications in a server or group of servers.Such applications may include applications that communicate with theS-CSCF of the IMS network and include a PS-UDF (public safety-user datafunction) which is operated by the Public Safety Administration andfunctions as a type of “mobile virtual network operator” and providesthe functions of the HSS required by the IMS and the public safetyapplication. Thus the PS-UDF, replaces the HSS.

Due to the replacement of the HSS, roaming with traditional virtualpublic land mobile networks (VPLMNs) could be required. However in someembodiments, EPC level security uses traditional HSS while the PublicSafety Administration uses a PS-UDF.

Other applications that may be part of a public safety authority servermay include a MCPTT server. In this case, the PS-UDF providesauthorization for mobile terminated call/session establishment andservice invocation an updates the S-CSCF with filter criteria to triggerthe services to be provided to the user by public safety applicationservers. The PS-UDF communicates with the MCPTT server and a groupmanagement function to support MCPTT services in the IMS. In oneembodiment, the MCPTT server is equivalent to a push to talk overcellular (PoC) server in the open mobile alliance (OMA) push tocommunicate for public safety (PCPS) architecture.

From the above, the architecture of the public safety service includesone or more servers which communicate with the IMS system through theS-CSCF and include a PS-UDF and a MCPTT server.

In operation, MCPTT may be deployed as described in FIG. 4. Inparticular, as described in FIG. 4, a public safety operator may have anapplications infrastructure 410, as well as a SIP IMS core supportingthe public safety operator 412.

A regular PLMN may then be used for certain signaling including an IP(EPC) core supporting the public safety operator 420, as well as anaccess network such as LTE 424.

A public safety UE 430 may include a group management client 432 as wellas an MCPTT client 434.

As seen by FIG. 4, control signaling between the applicationsinfrastructure of the public safety authority provide control signalingto a group management client 432 as well as the MCPTT client 434.

Further, user data and embedded control are provided to the MCPTT client434 from applications infrastructure 410.

In one use of the deployment model of FIG. 4, full control of the IMSlayer may be provided in which a cellular operator does not know whatdevice is being used for, or by whom. In this case, the device wouldhave a generic public user identity that would be used in the cellularnetwork. However, in the IMS network this identity would be changed withno visibility of the change to a cellular operator.

Extensible Authentication Protocol

Extensible Authentication Protocol is an extensible authenticationframework. It provides the necessary tools to incorporate otherauthentication schemes into the basic messaging structure. There are anumber of EAP mechanisms that have been created. One EAP mechanism isthe EAP-tunneled transport layer security (TTLS). In this authenticationscheme a client can be securely authenticated with an authentication,authorization and accounting (AAA) infrastructure by setting up a securetunnel between the client and a TTLS server, and then within a securetunnel allowing another authentication protocol to be used toauthenticate the client.

EAP-TTLS is, for example, described in the Internet Engineering TaskForce (IETF) request for comments (RFC) 5281 “Extensible AuthenticationProtocol Tunneling Transport Layer Security Authenticated Protocolversion 0”, August 2008, the contents of which are incorporated hereinby reference. Reference is now made to FIGS. 5A and 5B, which showprotocol stacks from Section 6 of RFC 5281.

In particular, as seen in FIG. 5A, when the user authentication protocolis not itself the EAP, EAP-TTLS packets are encapsulated within the EAPand the EAP in turn requires a carrier protocol to transport it.EAP-TTLS packets themselves encapsulate TLS, which is then used toencapsulate attribute-value pairs (AVPs), which may carry userauthentication or other information. Thus, as seen in FIG. 5A, theprotocol stack includes a carrier protocol layer 510, an EAP layer 512,an EAP-TTLS layer 514, a TLS layer 516 and an EAP layer 518.

When user authentication protocol is itself an EAP, the protocol stackis shown with regard to FIG. 5B. In particular, as seen in FIG. 5B, theprotocol stack includes an EAP layer 530, an EAP-TTLS layer 532, a TLSlayer 534 and a layer 536 for AVPs including EAP. However, the protocolstack further includes an EAP method layer 538 in which methods forencapsulating EAP within carrier protocols are already defined. Forexample, point to point protocol (PPP) or Extensible AuthenticationsProtocol over LAN (EAPOL) may be used to transport EAP between a clientand an access point RADIUS or Diameter are used to transport EAP betweenaccess point and TTLS server.

IMS Authentication for MCPTT

Thus MCPTT requires that any users should be able to pick up any deviceand use it. For example, a fire station may have a box of devices thatany firefighter may be able to pick up and use. Further, theauthentication of the MCPTT application needs to be independent of thecellular/IMS network to meet the security requirements of the PublicSafety service provider and Public Safety users and in some instances itmay be desirable to hide or obscure the identity or the role of the userthat is using a device. Thus, MCPTT does not fit well within the currentIMS authentication protocols.

In accordance with the embodiments of the present disclosure, variousauthentication schemes are described for providing separate public andprivate user identities. Further, methods and systems for obscuring theidentity of the user are also described. While the disclosure below isdescribed with regard to MCPTT, the use of the authentication systemsand methods described below can equally be used for other applications.Thus the present disclosure is not limited to MCPTT.

In the embodiments described below, solutions are provided for both inband signaling and out of band signaling. As used herein, in bandsignaling implies signals that utilize existing IMS messaging forauthenticating an IMS UE that are enhanced to carry additionalinformation to indicate a new form of authentication needs to beperformed. Further, as used herein, out of band signaling implies that anew signaling path is used other than that of the current signaling pathused to authenticate the IMS UE. In other words, the out of bandsignaling implies that the signaling currently used to authenticate theIMS UE is not enhanced and another mechanism is used to authenticate anindividual subscriber.

Various in band and out of band embodiments are provided below.

The embodiments described below are provided as complete embodiments.However, one skilled in the art will appreciate that parts of eachsolution can be used with other solutions to form other potentialsolutions. In addition, some encoding mechanisms are shown with specificimplementations. However, the specific implementations can be mixed andmatched across the various solutions. In addition, various changes tostandards are described in Appendices and tables. These show otherspecific embodiments and can equally be mixed and matched. One skilledin the art will appreciate that such example changes are used forillustrative purposes as well and the coding could be equally donenumerous other ways.

In Band—Indication for Double Authentication

In one embodiment, an IMS registration message is enhanced to contain anew indication. The new indication signals to the network that insteadof only authenticating the IMS Private User Identity (1st authenticationmechanism), that the IMS Public User Identity authentication also needsto be performed (2nd authentication mechanism). The indication may besent to authentication databases such as the HSS or PS-UDF to indicatethat two sets of authentication vectors are needed at the UE.

Reference is now made to FIG. 6. In the embodiment of FIG. 6, UE 610wishes to be authenticated with the IMS system. Communications mayproceed through a P-CSCF 612, an S-CSCF 614, an AAA 616, an HSS 618 anda PS-UDF 620. The logical elements of FIG. 6 however may be rearrangedand certain logic may be placed in other elements and therefore FIG. 6is merely an example. For example, the AAA server could be combined withthe PS-UDF. In another example, the PS-UDF could be combined with theHSS. Other examples are possible.

In FIG. 6, as well as in the remainder of the specification, variousnetwork nodes are identified, for example as MCPTT server, PS-UDF, HSSetc. However, in general each of these entities may be considered as oneof several network nodes interacting with each other to perform themethods described herein.

In the embodiment of FIG. 6, the UE 610 sends a message 630 to theP-CSCF 612. The message 630 contains various information including, butnot limited to, a first public user identity, a first private useridentity, and an indicator that indicates “double authentication”(Authentication of Private and Public user ID) is supported or needed.In one embodiment, the identifier of message 630 may be encoded as a newmechanism/name identifying a new security method. For example, suchmethod may be referred as IPSEC-MCPTT. Alternatively, or in addition,the identifier may be coded as mech-parameters in a security-clientfield, for example, as described in IETF RFC 3329.

In an alternative embodiment, the identifier in message 630 may be a newparameter in the authorization header field. For example, a new AKAversion number may be used.

In a further embodiment, the identifier may be encoded as an option tagin the supported or required header fields.

In a further embodiment, the identifier may be encoded as a feature tag.

Further, the identifier may be encoded as a universal resourceidentifier (URI) parameter such as, for example,“doubleauthentication=yes”.

In a further embodiment, the identifier may be encoded as an extensiblemarkup language (XML) body. It may also be encoded as a new header ormay be appended to either the first public user identity or a firstprivate user identity.

For example, in Table 1 below, items in bold represent some coding ofthe various methods described above. Table 1 below shows the variousoptions all placed within the same registration message. However, oneskilled in the art would know that in some circumstances only oneidentifier is needed and could be any of those shown in bold below. Inother circumstances there could be a plurality of indicators.

TABLE 1 Possible Changes to an IMS Registration Message REGISTERsip:registrar.home1.net\doubleauthentication=yes SIP/2.0 Via:SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From: <sip: home1.net!user1public@doubleauthentication>;tag=4fa3 To: <sip: home1.net!user1public@doubleauthentication> Contact:<sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000doubleauthentication=yes Call-ID: apb03a0s09dkjdfglkj49111Authorization: Digestusername=“home1.net!user1private@doubleauthentication”,realm=“registrar.home1.net”, nonce=“”, uri=“sip:registrar.home1.net”,response=“” Security-Client:ipsec-MCPTT; alg=hmac-sha-1-96;spi-c=23456789; spi- s=12345678; port-c=2468; port-s=1357 Require:sec-agree Proxy-Require: sec-agree CSeq: 1 REGISTER Supported: pathContent-Length: 0 Or REGISTER sip:registrar.home1.net SIP/2.0 Via:SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From:<sip:user1_public1@home1.net>;tag=4fa3 To: <sip:user1_public1@home1.net>Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000Call-ID: apb03a0s09dkjdfglkj49111 Authorization: Digestusername=“user1_private@home1.net”, realm=“registrar.home1.net”,nonce=“”, uri=“sip:registrar.home1.net”, response=“” Security-Client:ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678;port-c=2468; port-s=1357 Authorization: Digestusername=“user1_public@home1.net”, realm=“registrar.home1.net”,nonce=“”, uri=“sip:registrar.home1.net”, response=“” Security-Client:ipsec-MCPTT; alg=biometric finger prnt; spi-c=23456789; spi-s=12345678;port-c=2468; port-s=1357 Require: sec-agree Proxy-Require: sec-agreeCSeq: 1 REGISTER Supported: path Content-Length: 0

Similarly, 3GPP TS 24.229 may be changed in accordance with Appendix Aattached hereto. As shown in bold in Appendix A, additions to the textof TS 24.229 are provided. However, as with Table 1 above, variouschanges are all grouped into the Appendix A and one skilled in the artwill appreciate that only one change or a sub-combination of the boldchanges may be needed in practice.

Referring again to FIG. 6, once P-CSCF 612 receives message 630, itsends message 632 containing the contents of message 630 to S-CSCF 614.

S-CSCF receives message 632 and sends an authentication request message634 to HSS 618. One example of the changes that may be made for message634 in the 3GPP TS 29.228 Specification are provided in Appendix B inbold. As seen in Appendix B, the description of the authentication mayinclude biometric fingerprint data and IMS-AKA authentication, asexamples. However, the changes in Appendix B are merely meant asexamples.

An alternative embodiment is shown with regard to Appendix C, where theS-CSCF recognizes the second authentication digest header and includes anew MCPTT SIP authentication scheme attribute value pairs (AVP) with theindication of the authentication scheme to be used.

Specifically, as seen in Appendix C, an entirely new authenticationscheme is defined.

A 1^(st) database function, e.g. HSS 618 receives message 634 and maythen obtain authentication vectors from the 2^(nd) database functione.g. PS-UDF 620, as shown by messages 636. Specifically, the HSS mayobtain the set of vectors for a public user identity number from thePS-UDF as shown with regard to message 636 in FIG. 6. The HSS will sendthe authentication request message to the PS-UDF containing any or allof the data as identified above.

With regard to implementation, the HSS 618 may in some embodiments becombined with the PS-UDF 620.

The PS-UDF 620 receives the public user identity and will respond with aset of vectors. Vectors can include one or more of the followingchallenges, although the challenge response is not restricted to theexamples below. Specifically, an example set of vectors based on AKAare:

-   -   AV=RAND_(n)∥AUTN_(n)∥XRES_(n)∥CK_(n)∥IK_(n) where:    -   RAND: random number used to generate the XRES, CK, IK, and part        of the AUTN. It is also used to generate the RES at the UE.    -   AUTN: Authentication token (including MAC and SQN).    -   XRES: Expected (correct) result from the UE.    -   CK: Cipher key (optional).    -   IK: Integrity key.

The vectors could however be different based on the algorithm beingused. For example, the vectors may be based on the data communicated inthe SIP register, which is then converted into an entry in Appendix B. Amessage such as: Security-Client: ipsec-MCPTT; alg=biometric fingerprnt; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357 could beused.

Implementation wise the PS-UDF may be combined with the MCPTT server 619or the AAA server 616.

The HSS 618 may then provide the challenge vectors back to the S-CSCF614 in message 640. The challenge vectors in message 640 can be for thefirst private user identity and first public user identity. Challengevectors for the first public user identity may be encoded as any one ofa feature tag; XML body; AVP; or new header, among other possibilities.For example, Appendix D shows one possible change in bold to 3GPP 29.228for an AVP challenge.

In the embodiment of FIG. 6, the HSS has therefore included a second setof authentication vectors due to identification of a doubleauthentication scheme. The data that then follows this informationelement is associated with the first public user identity. In the changein Appendix D, the last four rows are data items associated with thesecond IMS AKA function but the authentication mechanism could be anyauthentication mechanism. Thus, the SIP-authenticate shown in theAppendix D contains a challenge that is presented to a first public useridentity. In addition, there is also a data item that the first publicuser identity can use to ensure it is being challenged by an authorizedentity.

The SIP-authorization elements in Appendix D are the expected results tothe challenge. S-CSCF 614 receives message 640 and provides message 642to P-CSCF 612. Message 642 provides the challenge vectors for both theprivate user and public user identities. For example, as seen in Table 2below, the bold section provides an addition to the message forauthentication. The bold section represents the 2^(nd) set ofauthentication vectors.

TABLE 2 Possible Changes to an Authenticate Request SIP/2.0 401Unauthorized Via: SIP/2.0/UDP icscf1_p.home1.net;branch=z9hG4bK351g45.1,SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 From:<sip:user1_public1@home1.net>;tag=4fa3 To:<sip:user1_public1@home1.net>; tag=5ef4 Call-ID:apb03a0s09dkjdfglkj49111 WWW-Authenticate: Digestrealm=“registrar.home1.net”, nonce=base64(RAND + AUTN  +  server specific  data), algorithm=AKAv1-MD5,ik=“00112233445566778899aabbccddeeff”,ck=“ffeeddccbbaa11223344556677889900” WWW-Authenticate:  Digest realm=“registrar.home1.net”, nonce=base64(CHALLENGE + AUTHN serverspecific data), algorithm=biometric  finger  prnt,ik=“00112233445566778899aabbccddeeff”,ck=“ffeeddccbbaa11223344556677889900”CSeq: 1 REGISTER Content-Length: 0

In Table 2 above, the second nonce is a construct of various sets ofdata that are similar to the 1st nonce. The use of such second nonce ismerely for illustrative purposes and one skilled in the art willappreciate that what is important is that the second nonce contains achallenge and additional data to verify if the challenge has come from alegitimate source.

P-CSCF 612 receives message 642 and forwards challenge vectors for thepublic user ID and private user ID to UE 610, as shown by message 644.Message 644 will typically contain the nonce, the algorithm to use, thesecond nonce and the second algorithm associated with the second nonce.

For example, reference is made to Table 3, which shows in bold additionsthat may be made to a message 644.

TABLE 3 Possible Changes to an Authenticate Request SIP/2.0 401Unauthorized Via: SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 From: To:Call-ID: WWW-Authenticate: Digest realm=“registrar.home1.net”,nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432;spi-s=87654321; port-c=8642; port-s=7531 WWW-Authenticate: Digestrealm=“registrar.home1.net”, nonce=base64(CHALLENGE + AUTHN + serverspecific data), algorithm=biometric finger prnt CSeq: Content-Length:

When the UE 610 receives message 644 containing two authenticationchallenge vectors, the second set of challenge vectors may be encoded asa feature tag, XML body, AVP, new header or www-authenticate-header,among others.

The UE 610 contains both a mobile element (ME) and a UICC. The MEperforms the first authentication. If a UICC is contained in the ME,then the authentication vectors may be sent across the ME-UICCinterface.

Either after the first authentication or during the first authenticationthe ME will run the second authentication challenge and the secondauthentication challenge is described in detail below.

One example of a change to the 3GPP TS 24.229 specification to supportsuch double authentication at the UE is shown with regard to Appendix Ebelow. In particular, Section 5.1.1.5 of 3GPP TS 24.229 has been amendedin the example of Appendix E to show that the UE can extract thechallenge and authentication parameters and check the validity of theauthentication parameter. If the authentication parameter is valid thenthe UE may execute the MCPTT application authentication.

Once the UE 610 has completed the first authentication, the UE may thensend an authentication response 650 containing two responses. The secondchallenge response may be encoded as any one of: a feature tag; XMLbody; AVP; a second authorization header; a new header; or appended tothe existing response value using a separator character eg, XXXXXyyyyyy, where XXXXX is the first response value and YYYYY is the secondresponse value, among other options. Such response values can be anynumber of characters in length.

Reference is made to Table 4 below, which shows a second authorizationheader including that contained in the second response in bold. The username is that of the first public user identity.

TABLE 4 Second Authorization Header REGISTER sip:registrar.home1.netSIP/2.0 Via:                 SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From:<sip:user1_public1@home1.net>;tag=4fa3 To: <sip:user1_public1@home1.net>Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; expires=600000Call-ID: apb03a0s09dkjdfglkj49111 Authorization:  Digest username=“user1_private@home1.net”, realm=“registrar.home1.net”,nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MD5, uri=“sip:registrar.home1.net”,response=6629fae49393a05397450978507c4ef1” Authorization:  Digest username=“user1_public@home1.net”, realm=“registrar.home1.net”,nonce=base64(CHALLENGE + AUTHN + server specific  data),algorithm=[ biometric  finger  prnt], uri=“sip:registrar.home1.net”,response=“6629fae49393a05397450978507c4ef1” Security-Client: ipsec-MCPTT;  alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678;port-c=2468; port-s=1357 Security-Verify: ipsec-MCPTT; q=0.1;alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642;port-s=7531 Require: sec-agree Proxy-Require: sec-agree CSeq: 2 REGISTERSupported: path Content-Length: 0

An example of a change to the 3GPP TS 24.229 for the response isprovided in bold in Appendix F below.

As seen in Appendix F, the response is provided with a second calculatedresponse appended to the first response, as shown in bold in Appendix F.

Message 650 is received at P-CSCF 612 and forwarded to S-CSCF 614, asshown by message 652. S-CSCF 614 may then perform, as shown by block654, a check of the expected responses. If both nonce and nonce2successfully match those stored in the S-CSCF 614 at block 641 in FIG.6, the UE 610 will be registered for MCPTT services. If the second noncedoes not match the value stored in the S-CSCF, the UE will only beregistered for IMS services. If the first nonce does not match the onestored in the S-CSCF 614, the UE 610 will not be registered for anyservices.

In an optional embodiment, if the S-CSCF 614 does not already have thestored vectors for the public user identity, a message 660 may be sentto HSS 618. An example of message 660 is shown with regard to AppendixG, which shows proposed changes in bold to 3GPP TS 29.228.

HSS 618 or other authentication function e.g. PS-UDF receives message660 and determines the request for authentication vectors is for thepublic user identity contained in the public user identity field. Thedetermination is based on indications identified above. In particular,Appendix H shows potential changes in bold to provide for authenticationrequest data in 3GPP TS 29.228.

The authentication function such as HSS 618 will either generate theauthentication vectors, request another function to generate theauthentication vectors by forwarding the message or using an alternativeprotocol. The authentication function such as HSS 618 then sends theauthentication vectors for the public user identity. Potential changesto 3GPP TS 29.228 are shown in bold by Appendix I.

As shown in Appendix I, the public user authentication vectors areprovided in the response. Thus, message 660 has the HSS including thesite of authentication vectors for the public user identity viaidentifying a public-user-authentication. The data that then followsthis information element is associated with the first public useridentity. One skilled in the art will appreciate that the last four rowsin Appendix I are data items associated with the second IMS AKA functionbut the authentication mechanism could be anything. Again, one aspect isthat the SIP-authentication contains a challenge that is presented tothe public user identity. For example, if a first public user identityis being authenticated, then the challenge is directed to that firstpublic authentication user identity. In addition, there are data itemsin the first public user identity data items in the message that thefirst public user identity can use to ensure that it is being challengedby an authorized entity. Further, the SIP authorization fields inAppendix I are the expected results of the challenge.

Referring again to FIG. 6, if the UE 610 has been registered for MCPTTservices, the S-CSCF 614 may send message 662 containing an indicationthat the second authentication has been successful to the authenticationfunction e.g. HSS, PS-UDF etc. This indication may be encoded as, butnot limited to, a feature tag, XML body, AVP or new header, amongothers.

An example of an AVP that could be updated is shown with regard toAppendix J. As shown in bold in Appendix J, changes to the 3GPP 29.229specification and in particular to Section 6.3.15 are provided.

Another example of a new AVP is shown with regard to Appendix K. InAppendix K the applications that are being registered for are identifiedin Section 6.1.3 of 3GPP TS 29.229, as shown in bold.

Message 662 may also be used if the UE has not been registered forpublic safety/MCPTT services and has only registered for either IMSservices. In this case, the S-CSCF 614 may send message 662 containinginformation pursuant to 3GPP TS 29.228.

In FIG. 6, once success has been confirmed with the S-CSCF 614, asuccess message 670 may be provided to UE 610.

In the above, when the UE receives data for the second authenticationchallenge, the UE needs to provide a response to the network. This maybe performed either at the ME or an application on the UICC. The resultmay be generated by either an automated or a manual process. Anautomated response could utilize an external authentication token. Theexternal authentication token could be swiped in a card reader in theME, the ME could communicate via wireless mechanism to an authenticationtoken, for example using Bluetooth™, near field communications (NFC),radio frequency identifier (RFID), among others. Basically the ME sendsa message to an external node and the external node responds back to theME with authentication credentials.

In a manual authentication, the ME provides an indication that could beany one of, but is not limited to, an audio, visual or other message.The ME receives data via keyboard, screen, movement of the ME,fingerprint reader, retina scanner, NFC, swipe car reader among otheroptions. The data received is then used as the challenge response andencoded in, for example, a MIME type message.

Thus, from the above, the IMS registration message is enhanced tocontain a new indication. The new indication signals to the network thatinstead of only authenticating the IMS private identity, the IMS publicuser identity authentication is also to be performed. The new indicationis also sent to the authentication database to indicate that two sets ofauthentication vectors are required.

The network, upon receipt of the new indication, will respond with twosets of authentication vectors instead of one or a single set ofauthentication vectors is associated with the IMS public user identityif a security association already exists for the IMPI.

A device should be capable of receiving two sets of authenticationvectors and upon successful validation of the IMS private user identityset, the device may then validate and run a second set of authenticationvectors. The second set of authentication vectors could be a password orsome other unique identification of the user such as fingerprint,QR-code from ID card, biometric data such as retina scan, among others.

A successful response from the device to the 1st set of authenticationvectors may allow the device to perform limited functionality in the IMSnetwork such as to receive configuration information.

A successful response to the 2^(nd) authentication vector allows thedevice to be used by a particular user. The exact functionality isdictated by the filter criteria and service description characteristicsassociated with that public user identity that has been successfullyauthenticated.

In Band-Second Public User Id and Authentication Response

In accordance with a further embodiment of the present disclosure, IMSregistration is performed as normal, including a first public useridentity and a first private user identity. However, when the deviceresponds to authentication challenge, it may also include new additionalinformation in the challenge response including a second public useridentity instead of the first public user identity that was sent in theinitial IMS registration.

In some embodiments, the UE may also provide a challenge response forthat second public user identity if it knows the challenge vectors forthe public user identities. In particular, if the same challenge vectoris utilized for the second public identity as was provided for the firstidentity, then the challenge response will be different but will bederivable at the network.

In one embodiment, the challenge response for the second public useridentity could be a password or some other unique identification of theuser such as a fingerprint, a QR code from an ID card or other biometricdata such as a retina scan, among others. In some cases, the secondpublic user identity may be sent either in clear text or may beencrypted or obscured by the device and therefore must be decrypted orunobscured by a network entity such as the HSS. If the second publicuser identity has been encrypted, an identifier may need to be providedduring the IMS registration to indicate such encryption. Encryption canbe based on a public key that is known to the device and the HSS, PS-UDFor Public Safety AAA server.

When the network receives the second public user identity that does notmatch the first public user identity, the S-CSCF may need to obtainauthentication vectors for the second public user identity. If thechallenge response for the second public user identity is correct forthe second public user identity, the network responds at the second useridentity as the one to be used for the device. However, if the challengeresponse is incorrect for the second public user identity, the networkresponds with the first public identity as the one to be used by thedevice.

Reference is now made to FIG. 7. In FIG. 7, UE 710 communicates with aP-CSCF 712. Further elements of the network include an S-CSCF 714, anAAA 716, an HSS 718, and a PS-UDF 720. Again one skilled in the art willappreciate that these are logical functions and could be combinedtogether.

In the embodiment of FIG. 7, UE 710 wishes to register with an IMSnetwork, for example a public safety IMS network. In this case, UE 710provides message 730 to the P-CSCF 712 which provides a first publicuser identity and a first private identity. The P-CSCF 712 receivesmessage 730 and forwards a message to S-CSCF 714, shown by message 732,which again provides the first user identity and the first privateidentity.

S-CSCF 714 then provides an authentication request 734 to HSS 718 andHSS 718 may obtain challenge vectors for the private identifier as andprovide them to the S-CSCF 714 in message 740. The challenge vectorsmay, in some instances, be obtained from the P-UDF 720, as shown byarrow 741.

The challenge vectors are then passed from S-CSCF 714 to P-CSCF 712 inmessage 742 and then to UE 710 in message 744.

The UE 710, upon receipt of the authentication challenge of message 744,provides message 750 back to the P-CSCF 712. If the UE supports MCPTTservice then the message may contain information consisting of, but notlimited to a first private user identity, a second public user identityand credentials associated with the second public user identity. Anoptional indication that the second public user identity and/orcredentials has been encrypted may also be provided if such is the case.

The information in message 750 may be encoded to include a newmechanism-name identifying the new security method. For example this maybe IPSEC-MCPTT and/or MEC-PARAMETERS in a security-client header field.For example, IETF RFC 3329 describes such encoding. Further, theencoding may be a new parameter in the authorization header field such anew AKA version as described in IETF RFC 3310. Further, the informationmay be encoded as an option tag in the supported or required headerfields, feature tags, URI parameters, XML body, new headers or appendedto either the first public identity or first private user identity.

For example, reference is made to Appendix L which shows a potentialchange to the 3GPP TS 24.229, and in particular to Section 5.1.1.5 ofthis specification. The bold sections of Appendix L are those which areadded.

Further, Table 5 shows potential changes in two implementations ofmessaging for providing for message 750.

TABLE 5 Authentication Response REGISTER sip:registrar.home1.net SIP/2.0Via: SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From:<sip:user1_public1@home1.net>;tag=4fa3 To: <sip:user1_public1@home1.net>Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; expires=600000Call-ID: apb03a0s09dkjdfglkj49111 Authorization: Digestusername=“user1_public@home1.net”, realm=“registrar.home1.net”,

=“public user authentication”, algorithm=“public user authentication”,uri=“sip:registrar.home1.net”,response=“6629fae49393a05397450978507c4ef1” Security-Client:ipsec-MCPTT; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678;port-c=2468; port-s=1357 Security-Verify: ipsec-MCPTT; q=0.1;alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642;port-s=7531 Require: sec-agree Proxy-Require: sec-agree CSeq: 2 REGISTERSupported: path Content-Length: 0 For purposes of discussion the noncein italics with be called nonce2. A second implementation could looklike following with the response to the 1^(st) challenge and secondAuthorization header with Public User ID and response REGISTERsip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From:<sip:user1_public1@home1.net>;tag=4fa3 To: <sip:user1_public1@home1.net>Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; expires=600000Call-ID: apb03a0s09dkjdfglkj49111 Authorization: Digestusername=“user1_private@home1.net”, realm=“registrar.home1.net”,nonce=base64(RAND + AUTN + server specific data), algorithm=AKAv1-MDS,uri=“sip:registrar.home1.net”,response=6629fae49393a05397450978507c4ef1” Security-Client: ipsec-3gpp;alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468;port-s=1357 Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Authorization:Digest username=“user1_public@home1.net”, realm=“registrar.home1.net”,

=“public user authentication”, algorithm=“public user authentication”,uri=“sip:registrar.home1.net”,response=“6629fae49393a05397450978507c4ef1” Require: sec-agreeProxy-Require: sec-agree CSeq: 2 REGISTER Supported: pathContent-Length: 0

P-CSCF 712 receives message 750 and forwards message 752 to the S-CSCF714. Message 752 includes the same information as message 750.

In the example of FIG. 7 and as shown by Table 5, the S-CSCF sees thatthe information received does not match with the information provided inmessage 732 and which was subsequently stored. Such information mayinclude the public user identity received in a username header, thenonce or the algorithm. The S-CSCF will then request authenticationvectors from the authentication function such as the HSS 718 or theP-UDF 720 or the AAA 716 if it does not already have stored vectors forthe public identity, shown by block 754.

The obtaining of vectors is shown by message 756 and is the same asmessage 660 from FIG. 6 above with the exception that the informationcontains the second user identity.

As seen in FIG. 7, message 752 provides the parameters and theauthentication response to allow for a successful authentication of thesecond public user identity. Thus, once the authentication is checkedfrom message 756, if the authentication is successful then message 760is provided between S-CSCF 714 and HSS 718.

Further, a success message 762 may be provided to UE 710, and suchmessage may be the same as that provided as message 670 of FIG. 6.

Conversely, if the authentication was not successful for the secondpublic user identifier, then the message 770 includes success, but onlyfor the first public user identifier, not the second public useridentifier. Message 772 therefore provides for success but utilizing thefirst public user identifier.

The above therefore allows for the obscuring of a public user identityand the authentication of such second public user identity using in-bandauthentication mechanism for ISM.

In Band Keying Based on Public User Id

In a further embodiment, IMS registration from the UE is performed asnormal with a new indication that authentication is also required forMCPTT or public user identification. This indication is sent to and fromthe S-CSCF and HSS/PS-UDF.

The key derivation process and challenge response process is enhanced toinclude a personal identification number (PIN) that is associated withthe public user identity that is being used to access the system. ThePIN is combined into the IMS AKA algorithm to create the authenticationvectors.

The term PIN, as used herein, is being used in a generic fashion and caninclude, but is not limited to, a set of alpha numeric characters, apicture, iris scan, biometric data, fingerprint, voice print, key card,barcode, Qcode, a combination of some or all of the above, among otheroptions.

Reference is now made to FIG. 8, which shows information flow for suchkeying. In particular, UE 810 communicates with P-CSCF 812, whichcommunicates with S-CSCF 814, AAA 816 and HSS 818. In some embodiments,HSS 818 may also communicate with a PS-UDF.

As seen in FIG. 8, the UE 810 sends message 830 including the publicuser identifier and private user identifier. This message is thenforwarded from P-CSCF 812 to S-CSCF 814, as shown by message 832. TheS-CSCF 814 may, upon receipt of message 832, provide the authenticationrequest to the AAA 816, as shown by message 834. AAA 816 provides theauthentication request to HSS 818 in message 836.

Challenge vectors are created and HSS 818 provides the challenge vectorsfor the private ID in message 840 to AAA 816. The challenge vectors arethen provided from AAA 816 to S-CSCF 814 in message 842.

The challenge vectors are then forwarded from the S-CSCF 814 to theP-CSCF 812 in message 844 and finally provided to UE 810 in message 846.UE, as described below, performs the authentication and provides anauthentication response 850 back to the P-CSCF 812. The authenticationresponse is then forwarded to S-CSCF 814 as shown by message 852.

If the S-CSCF 814 includes or has stored the challenge vector responsesthen a check may be made, as shown as block 854. Otherwise, a responserequest may be made between the S-CSCF 814 and HSS 818, as shown bymessage 860.

If the authentication is successful then message 862 is used for thedetermination and message 864 is provided back to UE 810.

In the above, the UE therefore sends a registration to the message tothe network which includes an indication that authentication isperformed for the MCPTT application. Such indication may be encoded asany one of: a new mechanism-name identifying a new security method suchas ipsec-MCPTT and/or mech-parameters in a Security-Client header field;a new parameter in the Authorization header field; an option tag in theSupported or Require header fields; feature tags; URI parameters; XMLbody; new headers; or appended to either the first Public User Identityor the first Private User Identity. An example encoded in Table 6 belowshows in bold the changes, where the new Security-Client has been calledthe “ipsec-3GPP-MCPTT”.

TABLE 6 MCPTT Authentication Encoding REGISTER sip:registrar.home1.netSIP/2.0 Via: SIP/2.0/UDP[5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards:70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=234151D0FCE11 From:<sip:user1_public1@home1.net>;tag=4fa3 To: <sip:user1_public1@home1.net>Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000Call-ID: apb03a0509dkjdfglkj49111 Authorization: Digestusername=“user1_private@home1.net”, realm=“registrar.home1.net”,nonce=“”, uri=“sip:registrar.home1.net”, response=“” Security-Client:ipsec-3gpp-MCPTT; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678;port-c=2468; port-s=1357 Require: sec-agree Proxy-Require: sec-agreeCSeq: 1 REGISTER Supported: path Content-Length: 0

Further, at the UE, upon receiving message 846, the UE may obtain achallenge response associated with the public user identity that wassent in the IMS registration message in the “from” header. The challengeresponse, which is referred to as the public user ID PIN, may then besent into a function to modify it, either at the ME or UICC, and thenfrom the ME the response may be sent across the ME-UICC to the UICC. TheUICC may receive the public user ID PIN and use it to generate keys andchallenge responses.

An example of potential changes to the 3GPP TS 31.103 specification areshown in bold in Appendix M below.

For the keying, S-CSCF 814 may be enhanced by sending the message to theauthentication function to obtain authentication vectors. The messagemay include an indication that it is for an MCPTT service and may beencoded as a feature tag, XML body, new AVP, the use of an existing AVPwith a new code point, or a new header.

The authentication function could be the HSS, AAA, PS-UDF or somecombination of the three.

The authentication request may be in the form described in Appendix Nbelow.

As seen in Appendix N, the authentication request may include a publicuser identity, private user identity, number of authentication items,authentication data, the S-CSCF name and routing information, amongother information.

Upon receipt of a message requesting authentication vectors for thepublic user identity being registered, the authentication functionobtains the private user ID PIN associated with the public identity inthe public identity AVP. Using the indication sent by the UE in message846, the authentication function generates or requests authenticationvectors and sends the response back within an indication of a newmechanism used to create the vectors. Such message may be encoded as,for example, a feature tag, XML body, new AVP, existing AVP using a newcode point or a new header, among other options.

Reference is now made to FIG. 9, which shows a possible key generationimplementation.

In particular, the key generation includes an HSS process 910 whichincludes the generation of a sequence number (SQN) block 812 and ageneration of a random number (RAND) block 914. These are fed intovarious function blocks labelled as F1 to F5 and shown with referencenumerals 920, 922, 924, 926 and 928.

In the embodiment of FIG. 9, block F1 920 includes inputs of the SQN,authentication management field (AMF) and RAND, and further includes akey value K. An authentication token (AUTN) consists of SQN⊕AK∥AMF∥MAC.

Further, blocks F2 to F5 include the key value K along with the RAND asinputs.

In the embodiment of FIG. 9, a new function F6, as shown by block 930 isalso provided as an input to block 920, 922, 924, 926 and 928. Block 930takes the public user id PIN as an input. The PIN may have been obtainedfrom the PS-UDF (2^(nd) authentication function).

On the UE side 935, the function f6 is shown by block 840 and has thepublic user id PIN as an input. Output from block 940 is provided tofunction block F1 942, as well as to block 944, block 946, block 948.Further, an encryption key K is also provided to these blocks as well asto block 950. RAND is provided also to block 950 and the SQN is derivedat block 954.

The UE can then verify that the MAC=XMAC and verify that the SQN is inthe correct range. Thus, FIG. 9 shows the key generation process wherebythe public user ID PIN is combined either with some or all of the F1 toF5.

In order to hide the public user ID PIN, the PIN may also be sentthrough a function F6.

In Band-Keying Based on Public User Id, Alternative Embodiment

In an alternative embodiment, the output of the IMS AKA algorithm is nowcombined with the public user ID key to create a set of authenticationvectors. In particular, the solution is similar to that above, but hasthe advantage that the operator of the HSS, which is traditionally apublic operator carrier, does not get visibility of the public user IDPIN. This is achieved by combining the PIN with the private user IDauthentication vectors in the AAA/PS-UDF instead of the HSS. The maindifference between this embodiment and the embodiment above is the wayin which the keys are generated, which is shown in FIGS. 10 and 11.

In particular, reference is now made to FIG. 10, which shows adiagrammatic view of the authentication vector generation in the HSS andAAA/PS-UDF. Note the HSS, AAA and PS-UDF could be a single node ormultiple nodes.

An HSS process block 1010 communicates with an AAA/PS-UDF process block1020. Thus, in accordance with the embodiment of FIG. 10, similar keygeneration blocks to those of FIG. 9, including an SQN block 1012, andRAND block 1014 are provided. Output from these blocks are input tofunction blocks 1030, 1032, 1034, 1036 and 1038. However, the outputfrom blocks 1030, 1032, 1034, 1036 and 1038 is provided to theAAA/PS-UDF process 1020 and thus the public user ID PIN is never used atthe HSS. Instead, the public user ID PIN is provided for block F6 asshown by block 1050 and can generate output for blocks 1060, 1062, 1064,1066, and 1068.

FIG. 11 shows a diagrammatic view of the authentication vectorgeneration at the UE. In particular, the parameter key may be used as aninput to function blocks 1110, 1112, 1114, 1116, and 1118. Further, theSQN can be generated at block 1120.

The public user ID PIN is provided at function block 1130 and may beprovided. Along with outputs of blocks 1110, 1112, 1114 and 1116, toblocks 1140, 1142, 1144, and 1146.

Thus the use of the public user id PIN may be kept secret from thecarrier.

While the solutions of FIGS. 9, 10 and 11 are provided above for in bandsolutions, they may be equally utilized with some of the out of bandsolutions described below.

Out of Band Signalling

In a further embodiment, out of band signaling may be used forauthenticating an IMS individual subscriber. Out of band signalingimplies that a new signaling path is used than the signaling currentlyused to authenticate the IMS UE. The out of band signaling mechanism canbe used either before or after IMS registration.

In a first embodiment, the device may signal to a network a firstauthentication procedure. This may, for example, be an EAP message thatauthentication is required. The message may contain the public useridentity for which the authentication is required, and optionally theprivate user identifier that the public user identifier is associatedwith. The network may respond with an authentication challenge that isappropriate to the EAP authentication mechanism being used.

Upon successful authentication of the public user identity, the UE thenprovides the same public user identity in an IMS registration message tothe network as well as the private identifier used in the firstauthentication procedure (if it was provided at all). This is known asthe second authentication procedure in the description below.

The network will then check that the public user identity has beensuccessfully authenticated and signal the public user identity back inthe response to the registration. If authentication of the public useridentity was unsuccessful, the network may respond with another defaultpublic user identity that is used for configuration purposes or mayallow the user a limited ability to contact staff to fix authenticationproblems, for example. Alternatively, the network may respond with anauthentication failure indication.

Keys for the second authentication mechanism may be generated, forexample, utilizing the techniques described above with regard to FIGS.9, 10 and 11.

Thus, in accordance with one embodiment of the present disclosure, theout of band solution links the public and private user IDs together.This means that only the public user ID can be used with a specificprivate user ID after the public user ID has been first authenticated.

Reference is now made to FIG. 12. In FIG. 12, a UE 1210 communicateswith a P-CSCF 1212. Further, various elements may include a S-CSCF 1214,an AAA 1216 and an HSS 1218. In some embodiments, a PS-UDF (not shown)may also be provided and could be co-located with the AAA 1216 and/orHSS 1218.

In the embodiment of FIG. 12, a first authentication mechanism 1220 isshown to be performed first. A second authentication mechanism 1222 isthen shown to be performed. However, in other embodiments the secondauthentication mechanism 1222 could equally be performed first and thefirst authentication mechanism 1220 performed subsequently. In thiscase, in one embodiment the response to the public user identityauthentication in the first authentication mechanism may need to alreadybe available to the UE and HSS for the second authentication.

The first authentication mechanism 1220 comprises various messages. Afirst message 1230 sent from UE 1210 to AAA 1216 typically contains atleast of a public user identity and optionally a private user identity.

AAA 1216 receives message 1230. If message 1230 does not contain twoidentities, then the network may send message 1232 back to UE 1210 toeither request both the public user identity and private user identityor, in other embodiments, to request only the public user identity.

One example of a change to the 3GPP TS 24.302 specification to allow forthe request of message 1232 is provided in Appendix O. As seen inAppendix O, an octet may be used to indicate the request for the variousidentities back to the UE.

Referring again to FIG. 12, once the UE receives message 1232, the UEdetermines whether or not to send one or both identities. If only oneidentity is sent back, EAP-AKA supports the sending of this one identityalready.

In one embodiment, the UE will additionally send a second identity usinga new encoding scheme. For example, referring to Appendix P, a possiblechange to the 3GPP TS 24.302 is provided in which the alternativeencoding scheme is provided.

The UE will then send message 1234 back to the network, for example toAAA 1216. However, in other embodiments the receiving party may be thePS-UDF or MCPTT AS or HSS 1218.

Once the network receives message 1234, it may then provide a message toHSS 1218 containing both the private user ID and public user ID, asshown by message 1240 in FIG. 12. HSS 1218 receives message 1240 andgenerates authentication vectors for the public user ID and providesthese back to AAA 1216 in message 1242. As described in previous in bandembodiments and other out of band embodiments, the HSS can communicatewith the PS-UDF to obtain authentication vectors. In addition the HSSmaybe a PS-UDF.

The AAA 1216 receives message 1242 and forwards the challenge vectors toUE 1210 in message 1244.

UE 1210 receives message 1244 and generates an authentication response,which is provided back to AAA 1216 in message 1250.

AAA 1216 receives the authentication response and forwards it to the HSS1218 in message 1252, which then checks the authentication response andprovides a result back in message 1254.

If message 1254 is a success message, the success may then be forwardedto UE 1210 in message 1256.

At this point, the first authentication mechanism 1220 has beensuccessful. In this case both the UE and the HSS mark the public user IDas the one to use against the private user ID, as shown by block 1260for the UE 1210 and block 1262 for the HSS 1218.

The process of FIG. 12 then proceeds to the second authenticationmechanism 1222. From a UE perspective, the UE performs IMS registrationper 3GPP TS 24.229 and includes the public user ID and private user IDdetermined in the first authentication mechanism 1220.

When the UE receives the 401k challenge from the network, it optionallyuses the response it used for the public authentication in the firstauthentication mechanism 1220 in creating the response that is put inthe SIP register to the network. For example, the mechanism of FIGS. 9,10 and 11 above may be utilized in which the response is the same as thepublic user identifier PIN.

From the HSS 1218 perspective, the HSS receives a request to provideauthentication vectors. These authentication vectors may be created asdescribed above with regard to FIGS. 9, 10 and 11, where the responsefor the public authentication in the first authentication step is thesame as the public user ID PIN. The HSS then ties the public user ID tothe private user ID. For example, a key overview is provided with regardto FIG. 13.

In FIG. 13, UE 1310 and HSS 1312 proceed through an authenticationprocedure. A first authentication process 1320 includes the public ID1322 as an input from both the UE and HSS.

The result of the first authentication process at each of UE 1310 andHSS 1312 is provided to the second authentication process 1330 andparticularly to an IMS AKA 1332 for the UE and IMS AKA 1334 for the HSS.Described another way, as part of the 1^(st) Authentication Process theHSS 1312 sends a challenge to the UE 1310. At the same time the HSScalculates the Response that it expects to get from the UE. The UEresponds to the challenge with a response. The Response generated by theUE is used as an input into IMS AKA 1332 and the Response generated bythe HSS is used as an input into IMS AKA 1334.

The IMS AKA 1332 includes an input for the private identifier at the UE.Similarly, IMS AKA 1334 includes an input for the private identifier atthe HSS.

The results of the second authentication processes (XRES) are providedto the S-CSCF 1340 which determines the success or failure.

The above therefore provides an out of band solution in which a publicuser ID is tied to a private ID prior to the IMS registration. However,as indicated above, the out of band authentication may also occur afterIMS registration in some embodiments.

Second Out of Band Embodiment

In an alternative embodiment, the solution provided above with regard tothe first out of band embodiment may be utilized. However, in asituation where a user of a first Public Safety Service provider isproviding assistance to a second Public Safety Service provider andneeds to use the MCPTT service of the second public safety userprovider, enhancements to the solution of FIG. 12 above may be made.

For example, if a first police officer of a first police force isassisting a second police force and needs to use the MCPTT service ofthe second police force, the embodiments described below with regard toFIG. 14 may be utilized. FIG. 14 may equally be used where first PublicSafety Service provider is same as the second Public Safety Serviceprovider.

In a second embodiment, the device performs a second authenticationmechanism. For example such authentication mechanism may be the IMSregistration with a second public user identity and a private useridentity.

The IMS third party registration is then performed with the MCPTT AS.The MCPTT AS uses an enhanced Sh interface and sends an indication thatthe user identity has been now successfully registered for the MCPTTservice.

The device may then perform a second authentication mechanism using afirst public user identity via a secure tunnel that was created as partof the first IMS registration or could be part of a secondauthentication mechanism such as EAP-TLS.

The first public user identity is the public user identity the UE wantsto use for communication. Upon successful authentication, the PS-UDFover an enhanced Sh interface signals that the first public useridentity and private user identity have been successfully authenticatedfor the MCPTT service.

Upon success of the second authentication, in one embodiment the deviceperforms a second IMS registration using the first public user identity.In an alternative embodiment, when the network indicates a successfulauthentication back to the device, the network element, such as the HSS,updates the P-CSCF with the first public user identity. This could beeither via an HSS-PCC-P-CSCF to modify the public user identities in theP-CSCF by using the PCC. Alternatively this may be used via HSS-S-CSCFwhere the Cx interface command or message that changes the public useridentity in the profile in the S-CSCF triggers a NOTIFY for theregistration event package to be sent to the P-CSCF to update theidentities that can be used with the private user identity.

Thus when the device sends an INVITE, the P-CSCF will assert the firstpublic user identity for any session originations.

The above therefore provides a way to trigger configuration mechanismsso that the UE can roam to a second MCPTT network and thus providemutual aid.

Reference is now made to FIG. 14. In the embodiment of FIG. 14, a UE1410 communicates with a P-CSCF 1412. Further, an S-CSCF 1414 and an AAA1416 are provided in the system.

Further, an MCPTT 1420, HSS 1422 and PS-UDF 1424 are provided in thesystem.

In the embodiment of FIG. 14, a second authentication mechanism 1430 isperformed first. In particular, the IMS authentication registration 1432utilizes a second public identity instead of a first public useridentity. This registration process allows the UE to get basic IMSservices but not MCPTT services.

The third party registration 1434 just registers the first private useridentity and a second public identity with the MCPTT service. The MCPTTservice then updates the PS-UDF 1424 with at least one of the privateuser ID, second public user identity, or device ID that have beenregistered with the MCPTT service.

The signaling for the above, may for example may be provided utilizing achange to the 3GPP TS 29.328. One example of such change is shown, withregard to Appendix Q.

As seen in Appendix Q, the IMS user state may be registered for aparticular service such as an MCPTT or not registered for a particularservice such as MCPTT.

Once the second authentication mechanism in which the second public useridentifier has been used is completed, a third party register messagemay be provided between the MCPTT 1420 and S-CSCF 1414, as shown bymessage 1434 and a subscriber message 1436 may be provided betweenP-CSCF 1412 and S-CSCF 1414.

Subsequently, the first authentication mechanism 1440 may be performed.The first authentication mechanism 1440 is the same as that providedabove with regard to the first authentication mechanism 1220 of FIG. 12.In particular, the first authentication mechanism utilizes a firstpublic user identity and a first private user identity for theauthentication. This is shown by message 1442 which is passed to the AAA1416. The first public user identity and private user identity are thenprovided to the PS-UDF 1424 in message 1444.

Challenge vectors are then provided for the first public user ID, asshown in message 1446, to AAA 1416. AAA 1416 then provides thesechallenge vectors to UE 1410 in message 1448.

The UE then provides an authentication response shown by message 1450 toAAA 1416. The authentication response is forwarded to the PS-UDF 1424 inmessage 1452. If the authentication process is successful, the PS-UDF1424 (or the AAA in some cases) updates the MCPTT server 1420, as shownby message 1460 via the Sh interface. An example message is shown withregard to Appendix K, as described above. The message on the Shinterface contains the 1^(st) Public User Identity and optionally thefirst private user identity. The MCPTT server is then able to correlatethat the 1^(st) Public User identity has been registered from the samedevice the 2^(nd) Public User identity was registered from in the 2^(nd)authentication mechanism. Equally the Sh interface can be used so theMCPTT server can provide the first private user identity and 2^(nd)Public User identity to the PS-UDF so it can create a relationshipbetween 1^(st) Public User identity, 2^(nd) Public User identity andfirst private user identity. The PS-UDF can then update the HSS withthis relationship, as shown by message 1474. The term “update” as usedherein means that the HSS may query the PS-UDF to determine if 1^(st)Public User identity can be used with the first private user identity,or PS-UDF provides information to the HSS so that it can create arelationship between 1^(st) Public User identity, 2^(nd) Public Useridentity and first private user identity.

Messages 1464 and 1466 may be provided to show success. In particularmessage 1464 is provided from PS-UDF 1424 to AAA 1416. The message 1466is provided from AAA 1316 to UE 1410.

The Sh notification could be enhanced to provide an indication thatauthentication for the MCPTT service has been successful. An examplemessage with enhancements is shown in Appendix R below.

As seen in Appendix R, possible changes to 3GPP TS 29.328 are providedwhich allow for a device to be registered or not registered for theservice X (can be MCPTT or PTT). Further, the information elementcontains a device ID of the device that the IMS user has registered forthe MCPTT services.

After the first authentication mechanism, a second authenticationmechanism 1470 may occur as described above with regard to the secondauthentication mechanism 1222 of FIG. 12.

Further, once the first authentication step has been successful the HSS1422 then updates the network to use different public user identity, twooptional elements are provided. In a first optional mechanism, the HSS1422 may update the PCC 1482 with an updated PCC message 1484. The PCCmay then update the P-CSCF 1412 in message 1486.

The P-CSCF 1412 may then translate incoming messages. Thus, the UE 1410may send an INVITE 1488 with the second public identity and this inviteis then translated at P-CSCF 1412 to reflect the first identity, asshown by message 1490.

In a further alternative, HSS 1422 may modify the profile for the firstpublic user identity, as shown by message 1494 which may be thennotified to P-CSCF 1412 in message 1495.

The UE 1410 may then provide an INVITE with the second user identity,shown by message 1496, which may be translated by the P-CSCF 1412.P-CSCF 1412 may then forward the INVITE, but having the first useridentity, as shown with message 1498.

Out of Band Mutual Aid

In a further embodiment of the out of band solution, a firstauthentication mechanism is performed in which additional enhancementsallow a network to request, and the UE to provide, information regardingthe PLMN it is registered on in the authentication mechanism. This PLMNinformation is then used to determine which public service safetyprovider should be contacted.

A new message is sent from the MCPTT server of the first public safetyoperator to the PS-UDF of the second public safety operator to request aprivate user ID. It may be that such message includes the public user IDof the user being authenticated.

The PS-UDF of the second public safety operator then provides back theprivate user ID and public user ID. This information may be then sent tothe UE via messaging such as open mobile alliance (OMA) devicemanagement, hypertext transfer profile (HTTP), XML Configuration AccessProtocol (XCAP), or over the air (OTA) message to the USIM or ISIMapplication, where new fields are present that store this information.

The UE may then perform a second authentication mechanism using the newprivate and public user identifiers. When the PS-UDF of the secondsafety operator receives the second authentication mechanism, it thencontacts the PS-UDF of the first public safety operator to obtain thecredentials and uses them to authenticate the user.

Reference is now made to FIG. 15 in which a UE 1510 communicates througha TTLS/IPSec server 1512 with a PS-UDF 1514 and MCPTT server 1516 of thefirst MCPTT operator 1520. An S-CSCF 1522 of PLMN 1524 is utilized forthe MCPTT of the first operator 1520. Note that TTLS/IPSec server 1512could be combined with either or both of the PS-UDF 1514 and MCPTTserver 1516. Such an implementation is shown as a dotted line 1590.

A second MCPTT operator 1526 has a second PS-UDF 1528.

In the embodiment of FIG. 15, UE 1510 contains a first private useridentity, a second public user identity, a device identity and acertificate that could be linked to the first private and/or public useridentity.

A first authentication mechanism 1530 is provided. As part of anoptional first part of authentication mechanism 1530, UE 1510 could setup a TTLS/ipsec tunnel with a TTLS/ipsec server 1512, as shown bymessages 1532. In one embodiment the TTLS/ipsec server could be an AAAserver, a PS-UDF or an MCPTT AS, or could be a combination of some orall of these servers.

The UE 1510, as part of the tunnel setup, includes a certificate.Possible certificate mechanisms are described below. The certificate mayhave a relationship between the device and/or private user ID being usedwith that device. As part of such mechanism, the network may requestspecific attributes from the UE. Such attributes may include, but arenot limited to: an identity that identifies the user equipment and anetwork that the UEs registered on.

These attributes are requested by sending a request from the network tothe UE. If the TTLS/ipsec server 1512 communicates with a AAA server(not shown) or a PS-UDF, then the AAA server or the PS-UDF could sendthe attribute request via the TTLS/ipsec server to the UE. Or, if all ofthe servers are combined in a network node then the network node sendsthe request to the UE for the attributes.

EAP extension attributes may be provided for such request. These are,for example, shown in Appendix S, which shows that an octet may be usedfor requesting certain information.

A first authentication mechanism may then be used. Examples of suchfirst authentication mechanisms are described above with regard to FIG.12 or 14.

As shown by message 1534, the authentication mechanism may providecertain information. In one option the UE may send an identity includinga second public user identity to be authenticated. Optional additionalinformation to be sent may include, but is not limited to, a deviceidentifier that identifies the equipment and/or a network that the UE isor was registered on. This additional information may be obtained by thenetwork node, for example by PS-UDF 1514 sending a message to the UE.Such message may include indicators that ask for additional information,including for example the PLMN the UE is registered on, the device ID,among other information. The UE receives this message and sends amessage to the network, for example to the PS-UDF, containing a deviceidentifier that identifies the equipment and/or a network that the UE isor was registered on.

The additional information may be sent based on the receipt, at the UE,of the request of a message as shown in Appendix S.

Upon successful authentication, the PS-UDF 1514 sends an indication tothe MCPTT AS 1516 that authentication for the second public useridentity has been successful. This is shown in message 1536. The firstprivate user identity, first public user identity, second public useridentity, PLMN and IMEI may also be indicated. The PS-UDF 1514 in oneimplementation could be the MCPTT AS. One example of possible changes tothe 3GPP TS 24.302 specification for this are shown with Appendix Tbelow. Note the first public user identity could have been derived fromthe certificate exchange that has taken place in authenticationmechanism 1530 and is explained in more detail below.

Once the first authentication mechanism 1530 is finished, aconfiguration mechanism 1540 may occur. One skilled in the art willappreciate that the authentication mechanism shown in message 1534 canbe exploded out to be that as described in but not limited toauthentication mechanisms 1440, 1220, among others.

During the configuration mechanism, a message 1542 may be provided fromUE 1510 to the MCPTT AS 1516. Message 1542 may optionally provide aconfiguration request to the network. It may contain the PLMN identityof the network that the UE has registered on. This request may occurbecause the UE uses OMA management objects for configuration of theMCPTT identities.

MCPTT AS 1516 may then request a second private identifier and 3^(rd)public user identity from the second MCPTT operator 1526 as shown bymessage 1544. Message 1544 may contain 0 or more of: a first privateuser identity, a first public user identity, a second public useridentity. The MCPTT operator 1526 may be derived based on staticconfiguration or by performing a DNS look up on the PLMN identity thatthe UE is registered with.

The second PS-UDF 1528 receives message 1544. In one embodiment theMCPTT AS may only send the first public user ID to the second PS-UDF1528 in order to ensure that the first private user ID is not released.

The second PS-UDF 1528 associates the second private user ID with thefollowing, if received: the first private user identity; the firstpublic user identity; the second public user identity; and/or theequipment identity.

PS-UDF 1528 sends at least one of the second private user identity and athird public user identity back in message 1546. MCPTT AS 1516 receivesat least one of the second private user identity and the third publicuser identity.

The UE may then be provisioned with data. A data model can be found inFIG. 16 below, where the UE is provisioned with the private identifierand public identifier. Those skilled in the art will appreciate thatthis is an example of an OMA Device Management (DM) Object thatdescribes a set of data. However it can be equally used as an abstractdata model. For example, the private identifier could be an IMSI asdefined in E.212 or a network address indicator (NAI) as defined in RFC4282. The public ID could be an MSISDN as defined by E.164 or an NAI asdefined by RFC 4282 whereby the NAI also may contain a digit stringsthat represents the MSISDN.

A validity area for these identities that could be specific to a PLMN, aregion within the PLMN, geographical area or even WLAN or combinationthereof.

For the purposes of describing FIG. 16 the analogy of a book/novel shallbe used. However, as identified, OMA DM describes the nomenclature ofthe diagrams in detail. Thus, referring to FIG. 16, an MCPTT 1610 mayhave 0 to multiple pages, as shown by block 1612.

In the embodiment of FIG. 16, a question mark indicates an optionalelement. Thus, one option element includes a series of identifiers 1620.Each identifier may either be a private identifier 1622 or a publicidentifier 1624, and may include various paragraphs (e.g. sets of dataitems) 1626 and 1628 which may include IMSIs or private user identifiersor MSISDNs or public user identifiers. Note a set may contain 0 to manyentries.

The pages may each also contain a validity area 1630. The validity areamay be based on a 3GPP location 1632, a 3GPP2 location 1634, a WLANlocation 1636 or a geographic location 1638, among others.

Each location may then have several criteria to make determinations.Thus, a 3GPP location may have various paragraphs 1640, and may includeinformation such as a PLMN, Type Allocation Code (TAC), Location AreaCode (LAC), GSM Edge Radio Access Network (GERAN) Cell Identifier (CI),Universal Mobile Telecommunications Service (UMTS) Terrestrial RadioAccess Network (UTRAN) CI, Evolved Universal Terrestrial Radio Access(EUTRA) CI, among other information.

A 3GPP2 location may have a check to determine if the connection is a 1×connection as shown by block 1650 in which case multiple paragraphs 1552may be provided. Information in these paragraphs may include system ID(SID), network ID (NID) or a base ID.

Similarly, if the 3GPP location is high rate packet data (HRPD) as shownby block 1654, then multiple pages 1656 may be provided. These pages mayinclude information such as a sector ID or netmask.

A WLAN location 1636 may have various paragraphs 1662. Information inthese paragraphs may include a homogenous extended service setidentifier (HESSID), a service set identifier (SSID), or basic serviceset identifier (BSSID), among other information.

A Geograpic location 1638 may have a check to determine if it is acircular location shown by block 1670 in which case multiple paragraphs1672 may be provided. Information in these paragraphs may include ananchor latitude, an anchor longitude, and a radius, among otherinformation.

Further, the geographic location 1638 may check this to determine if thelocation is a polygon as shown by block 1684, in which case multipleparagraphs 1686 may be provided.

Paragraphs 1686 may include including coordinates 1688, which themselveshave multiple paragraphs 1690. Information in paragraphs 1690 mayinclude latitude and longitude.

Referring again to FIG. 15, once a MCPTT 1516 receives the informationof message 1546 then a configuration may occur between the UE and theMCPTT, as shown with arrow 1550. In arrow 1550, if the USIM/ISIM isused, the MCPTT AS sends a message containing a least of, but notlimited to, the second private user ID and the third public user ID, andoptionally PLMN information.

In one embodiment, messages 1546 and 1550 are optional, and in thiscase, the MCPTT AS 1516 would need to generate the third public user ID.However, in this case the second private user ID would not be generated.

In the MCPTT AS 1516, a mapping occurs between some or all of thefollowing: a first private user identity; a first public user identity;a second public user identity; an equipment identity; a second privateuser identity; and a third public user identity.

Message 1550 could be short message service (SMS) message containingOver The Air (OTA) information. The over the air message sequence couldinclude a USAT REFRESH command with a qualifier “MCPTT private user IDupdate”.

The UE, upon receipt of the configuration information at message 1550could decode the message. The SMS destination address could be secondpublic user ID. In one embodiment Appendix U shows possible changes tothe 3GPP TS 31.103 specification which could equally apply in 3GPP TS31.102.

Further, the command details could be provided in accordance withAppendix V, which show possible changes to the ETSI TS 102 223specification.

If the ME receives a USAT REFRESH command qualifier of type “MCPTTprivate user ID update”, the ME can update the private identifier on thedevice.

Alternatively, if an OMA DM, HTPP or XCAP are used then the UE receivesthe configuration for the UE by sending a message to the network (e.g.MCPTT AS etc). The network will respond back with configurationinformation which can include one or more of a private ID, public ID andnetwork code. The information that may sent is shown with regard to FIG.16.

Once the configuration mechanism 1540 is complete, a secondauthentication mechanism 1560 could occur. The second authenticationmechanism 1560 includes a registration message 1562. Such message may bea SIP Register containing the second private user ID and optionally athird public user identifier. If the second private user ID was notreceived in the configuration information of message 1550, then thefirst private user ID would need to be used with the third public useridentifier.

As will be appreciated by those in the art, the public and private useridentifiers to use will be based on the PLMN that the UE is registeredon. This means that if the ME may compare the registered PLMN (RPLMN)with the PLMNs in the validity area/3GPP location/<x>/PLMN leaf of FIG.16. If there is a match then the public and private user ID that areused are associated with that PLMN. When the information is stored onthe USIM/ISIM as shown in Appendix U the ME will compare the RPLMN withthe PLMN field and choose the appropriate data.

The S-CSCF receives message 1562 and may optionally provide message 1564to PS-UDF 1528. Message 1564 only occurs if the second private useridentity has been used in message 1562. The second PS-UDF 1528 receivesmessage 1564 and PS-UDF 1528 may use this information to create amapping. Message 1566 may then be sent to MCPTT 1516 to obtain theauthentication vectors for the first private ID if available, otherwisefor the first public user ID. For example, message 1566 contains withinits contents the first private ID if available and or the first publicuser ID.

MCPTT 1516 receives the message, and sends message 1570 to the PS-UDF1514 requesting authentication vectors for the first private ID ifavailable and/or the first public user ID. If the first public user IDwas received, the MCPTT AS will use the mapping created above todetermine the private user ID.

PS-UDF 1514 receives message 1570 requesting authentication vectors andgenerates the vectors. PS-UDF then sends message 1572 containing theauthentication vectors for the first private user ID back to MCPTT 1516.

The MCPTT 1516 receives message 1572 containing the authenticationvectors for the first private user ID and sends the message to thesecond PS-UDF 1528, as shown by message 1574. The second PS-UDF may thengenerate vectors for the third public user identity and second privateuser identity and these may be forwarded to the UE, as shown by messages1580 and 1582.

As will be appreciated by those skilled in the art, FIG. 15 is merely anexample. In alternative embodiments, the UE may perform the secondauthentication first, using the private user identity and public useridentity stored on the UE. The UE may then perform the firstauthentication mechanism subsequently.

Further, in the context of the disclosure above, a second authenticationmechanism is described in numerous embodiments with labels 1222, 1430,1470, 1560. One will appreciate that the examples are based upon the SIPREGISTRATION procedure that as also includes an optional authenticationcomponent. Such SIP registration process has been described above withregards to FIG. 2. Per 3GPP TS 33.203, the 2nd Authentication mechanismstarts by UE sending a SIP Register message to the network, the UE thenreceives a message from the network that contains the authenticationchallenge to which the UE will respond with another Register message.

Certification Generation Processes

In a further embodiment, instead of the enhancements to the protocolslisted above to obtain private IDs, public IDs and device IDs, it isalso possible to use certificates which could be used as well inconjunction with those embodiments described above.

The UE performs a first authentication mechanism procedure as describedabove and sets up a tunnel. After the tunnel has been set up,authentication of the first public user identity can take place usingany authentication scheme. Examples of such authentication schemesinclude EAP, challenge handshake authentication protocol (CHAP),password authentication protocol (PAP), or message-digest 5 (MD-5),among others.

Thus, a first secure tunnel is set up between the UE and the network andthen, within the tunnel, authentication of the public user identitytakes place.

In the initial tunnel set-up a certificate may be provided. This, forexample, could be an x.509 certificate. The certificate may be createdin a new way in accordance with the description below. In oneembodiment, the certificate may be pre-provisioned and may be linked toeither the device ID or the private user identifier from the UICC.

The setting up of a tunnel creates a relationship in the network betweenthe device and the private identifier. Then the public user identityauthentication phase starts between the ME and the AAA server. If theAAA server is co-located with TTLS server, then there is a relationshipin the TTLS server between the device ID, private ID, and public userID. The TTLS/AAA server could be an IMS AS and in the context of thedescription above it may also be an MCPTT AS.

The UE performs a second authentication mechanism such as an IMSregistration, which may take place either before or after the firstauthentication mechanism (e.g. the second authentication mechanism couldhave been an EAP-TTLS procedure). In the IMS registration the deviceincludes the private user identifier that is linked to the certificatein the first authentication mechanism (e.g. that could have beenEAP-TTLS operation) and a second public user identity. The S-CSCF in theIMS network performs a third party registration with the MCPTT AS whichmay include, but is not limited to, the IMS private user identifier, asecond public user identifier for IMS and a device identifier.

At this point, there is now a linkage between the MCPTT AS and the IMSprivate user identifier, the second IMS public user identifier, thefirst public IMS user identifier and the device identifier.

Now when the MCPTT AS receives session requests, it has the option tohide the IMS second public user ID from the IMS network.

Reference is now made to FIG. 17, which shows a UE 1710, P-CSCF 1712, afirst public safety authority 1714 having a S-CSCF 1716 and an MCPTT AS1718.

The MCPTT AS 1718 includes a PS-UDF 1720 and an AAA 1722.

A second public safety authority 1724 includes HSS 1726.

In the embodiment of FIG. 17, a second authentication mechanism 1730occurs first, in which a registration between the UE and the secondpublic safety authority happens. Registration includes the first privateidentity and a second public identity. In particular, as shown by block1732 the registration includes the first private ID and second publicuser ID.

Based on the registration message of block 1732, a third partyregistration 1734 may occur.

The UE will start the second authentication process using the firstprivate user ID and second public user ID stored in the IMSI on thedevice. Upon completion of the process, the S-CSCF will do a third partyregistration with the MCPTT AS. In the third party registration thefirst private user ID and second public user ID are included. The MCPTTserver will receive this information and then map the first private userID with the second public user ID against data stored.

Upon successful second authentication, a first authentication mechanism1740 starts. The first part of the first authentication mechanism 1740is a tunnel setup 1742. In the example of FIG. 17, it is the MCPTT AS1718 that has the authentication function and the tunnel setup with theMCPTT AS.

As shown by block 1744, tunnel authentication next takes place.Certificates are exchanged between the UE and the network. Thecertificate is such that some or all of the following may be derivedfrom it: the first private user ID on the (U)/ISIM; the second publicuser ID on the (U)/ISIM; and the IMEI or device identifier. During thetunnel setup authentication process, the MCPTT AS 1718 will create adatabase of the relationship between these items.

As shown by block 1746, after successful creation of the tunnel anotherauthentication process will be started to authenticate the public userID that is using the device. For example, such ID may be police officercredentials. This will be called the first public user ID.

Upon successful authentication the MCPTT will associate this identifierwith the information stored in the database described above, as shown byarrow 1750.

Examples of certificates are provided below.

First Certificate Option

Reference is now made to FIG. 18 which shows a device detecting a newprivate identifier at block 1810 and generating a certificate at block1812. The generating certificate includes the device identifier 1814 anda private identifier 1816 as inputs to the generation block 1812. Blocks1810 and 1816 both contain the same Private User identity.

A certificate 1820 is provided as an output to generation block 1812.

In one embodiment the device may or may not contain an initialcertificate. Upon detection of a new UICC being inserted into the deviceor the detection that the IMSI or UICC code has changed, or a new USIMor ISIM is activated then the device will request a new certificate. Theactivation may, for example, be that the IMSI or IMS private useridentity has changed.

The certificate that is created will identity the UICC/USIM/ISIMcombination with the ME.

Second Certificate Option

In a second certificate option, a device ME_A is provisioned with afirst certificate, where the first certificate contains a first publickey that is used to verify signatures created by a first private key.The first private key is also provisioned to the ME_A.

USIM_A is inserted into the device with IMSI_A and a User_A logs intothe device using UserIdA and pwdA.

Device ME_A signs [IMSI_A, pwdA, T_now] at time T_now to form thesignature SigA.

Device sends CertA, SigA, [IMSI_A, UserIdA T_now] to the public safetyoperator who can now:

-   -   1) Identify ME_A from CertA    -   2) User_A from UserIdA and pwdA (assuming the public safety        operator has its own copy of pwdA)    -   3) USIM_A from IMSI_A

All of these identities may be authenticated by verifying SigA where:

-   -   1) The signature SigA is computed using IMSI_A, UserIdA and        KeyA, T_now.    -   2) The signature SigA is authenticated using SigA, IMSI_A,        UserIdA, T_now and PubKeyA

The above therefore provides means to authenticate a user of a shareddevice without the need to change the UICC. The solutions providevarious degrees of confidentiality of the user using the phone. Thelater out of band solutions provide means to hide a user, thus allowingthe public safety operator to decide what information should be visiblein the IMS network. They also provide various degrees of linkage betweenthe IMS authentication mechanism and the user authentication mechanism.

The above creates a linkage so that the user, when authenticated on thatdevice has to continue a session on that device unless they areauthenticated again. The single logon does not allow a user to swap UICCSIM cards between devices for malicious purposes. Certificates on thedevice can be such that they can only be provisioned by the publicsafety operator, allowing only valid devices to be used on the network.

The servers and network elements in the embodiments of FIGS. 1 to 17above can be any network element, or part of any network element,including various network servers. Reference is now made to FIG. 19,which shows a generalized network element.

In FIG. 19, network element 1910 includes a processor 1920 and acommunications subsystem 1930, where the processor 1920 andcommunications subsystem 1930 cooperate to perform the methods of theembodiments described above.

Processor 1920 is configured to execute programmable logic, which may bestored, along with data, on network element 1910, and shown in theexample of FIG. 19 as memory 1940. Memory 1940 can be any tangible,non-transitory, storage medium.

Alternatively, or in addition to memory 1940, network element 1910 mayaccess data or programmable logic from an external storage medium, forexample through communications subsystem 1930.

Communications subsystem 1930 allows network element 1910 to communicatewith other network elements. Examples of protocols for communicationsubsystem 1930 include cellular, Ethernet, WiFi, WiLAN, among others.

Communications between the various elements of network element 1910 maybe through an internal bus 1950 in one embodiment. However, other formsof communication are possible.

Further, the above may be implemented by any UE. One exemplary device isdescribed below with regard to FIG. 20.

UE 2000 is typically a two-way wireless communication device havingvoice and data communication capabilities. UE 2000 generally has thecapability to communicate with other computer systems on the Internet.Depending on the exact functionality provided, the UE may be referred toas a data messaging device, a two-way pager, a wireless e-mail device, acellular telephone with data messaging capabilities, a wireless Internetappliance, a wireless device, a mobile device, or a data communicationdevice, as examples.

Where UE 2000 is enabled for two-way communication, it may incorporate acommunication subsystem 2011, including both a receiver 2012 and atransmitter 2014, as well as associated components such as one or moreantenna elements 2016 and 2018, local oscillators (LOs) 2013, and aprocessing module such as a digital signal processor (DSP) 2020. As willbe apparent to those skilled in the field of communications, theparticular design of the communication subsystem 2011 will be dependentupon the communication network in which the device is intended tooperate.

Network access requirements will also vary depending upon the type ofnetwork 2019. In some networks network access is associated with asubscriber or user of UE 2000. A UE may require a removable useridentity module (RUIM) or a subscriber identity module (SIM) card inorder to operate on a CDMA network. The SIM/RUIM interface 2044 isnormally similar to a card-slot into which a SIM/RUIM card can beinserted and ejected. The SIM/RUIM card can have memory and hold manykey configurations 2051, and other information 2053 such asidentification, and subscriber related information.

When required network registration or activation procedures have beencompleted, UE 2000 may send and receive communication signals over thenetwork 2019. As illustrated in FIG. 20, network 2019 can consist ofmultiple base stations communicating with the UE.

Signals received by antenna 2016 through communication network 2019 areinput to receiver 2012, which may perform such common receiver functionsas signal amplification, frequency down conversion, filtering, channelselection and the like. A/D conversion of a received signal allows morecomplex communication functions such as demodulation and decoding to beperformed in the DSP 2020. In a similar manner, signals to betransmitted are processed, including modulation and encoding forexample, by DSP 2020 and input to transmitter 2014 for digital to analogconversion, frequency up conversion, filtering, amplification andtransmission over the communication network 2019 via antenna 2018. DSP2020 not only processes communication signals, but also provides forreceiver and transmitter control. For example, the gains applied tocommunication signals in receiver 2012 and transmitter 2014 may beadaptively controlled through automatic gain control algorithmsimplemented in DSP 2020.

UE 2000 generally includes a processor 2038 which controls the overalloperation of the device. Communication functions, including data andvoice communications, are performed through communication subsystem2011. Processor 2038 also interacts with further device subsystems suchas the display 2022, flash memory 2024, random access memory (RAM) 2026,auxiliary input/output (I/O) subsystems 2028, serial port 2030, one ormore keyboards or keypads 2032, speaker 2034, microphone 2036, othercommunication subsystem 2040 such as a short-range communicationssubsystem and any other device subsystems generally designated as 2042.Serial port 2030 could include a USB port or other port known to thosein the art.

Some of the subsystems shown in FIG. 20 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 2032 and display2022, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions such as a calculator or tasklist.

Operating system software used by the processor 2038 may be stored in apersistent store such as flash memory 2024, which may instead be aread-only memory (ROM) or similar storage element (not shown). Thoseskilled in the art will appreciate that the operating system, specificdevice applications, or parts thereof, may be temporarily loaded into avolatile memory such as RAM 2026. Received communication signals mayalso be stored in RAM 2026.

As shown, flash memory 2024 can be segregated into different areas forboth computer programs 2058 and program data storage 2050, 2052, 2054and 2056. These different storage types indicate that each program canallocate a portion of flash memory 2024 for their own data storagerequirements. Processor 2038, in addition to its operating systemfunctions, may enable execution of software applications on the UE. Apredetermined set of applications that control basic operations,including at least data and voice communication applications forexample, will normally be installed on UE 2000 during manufacturing.Other applications could be installed subsequently or dynamically.

Applications and software may be stored on any computer readable storagemedium. The computer readable storage medium may be a tangible or intransitory/non-transitory medium such as optical (e.g., CD, DVD, etc.),magnetic (e.g., tape) or other memory known in the art.

One software application may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to the user of the UE such as, but not limited to, e-mail,calendar events, voice mails, appointments, and task items. Naturally,one or more memory stores would be available on the UE to facilitatestorage of PIM data items. Such PIM application may have the ability tosend and receive data items, via the wireless network 2019. Furtherapplications may also be loaded onto the UE 2000 through the network2019, an auxiliary I/O subsystem 2028, serial port 2030, short-rangecommunications subsystem 2040 or any other suitable subsystem 2042, andinstalled by a user in the RAM 2026 or a non-volatile store (not shown)for execution by the processor 2038. Such flexibility in applicationinstallation increases the functionality of the device and may provideenhanced on-device functions, communication-related functions, or both.For example, secure communication applications may enable electroniccommerce functions and other such financial transactions to be performedusing the UE 2000.

In a data communication mode, a received signal such as a text messageor web page download will be processed by the communication subsystem2011 and input to the processor 2038, which may further process thereceived signal for output to the display 2022, or alternatively to anauxiliary I/O device 2028.

A user of UE 2000 may also compose data items such as email messages forexample, using the keyboard 2032, which may be a complete alphanumerickeyboard or telephone-type keypad, among others, in conjunction with thedisplay 2022 and possibly an auxiliary I/O device 2028. Such composeditems may then be transmitted over a communication network through thecommunication subsystem 2011.

For voice communications, overall operation of UE 2000 is similar,except that received signals would typically be output to a speaker 2034and signals for transmission would be generated by a microphone 2036.Alternative voice or audio I/O subsystems, such as a voice messagerecording subsystem, may also be implemented on UE 2000. Although voiceor audio signal output is generally accomplished primarily through thespeaker 2034, display 2022 may also be used to provide an indication ofthe identity of a calling party, the duration of a voice call, or othervoice call related information for example.

Serial port 2030 in FIG. 20 would normally be implemented in a personaldigital assistant (PDA)-type UE for which synchronization with a user'sdesktop computer (not shown) may be desirable, but is an optional devicecomponent. Such a port 2030 would enable a user to set preferencesthrough an external device or software application and would extend thecapabilities of UE 2000 by providing for information or softwaredownloads to UE 2000 other than through a wireless communicationnetwork. The alternate download path may for example be used to load anencryption key onto the device through a direct and thus reliable andtrusted connection to thereby enable secure device communication. Aswill be appreciated by those skilled in the art, serial port 2030 canfurther be used to connect the UE to a computer to act as a modem.

Other communications subsystems 2040, such as a short-rangecommunications subsystem, is a further optional component which mayprovide for communication between UE 2000 and different systems ordevices, which need not necessarily be similar devices. For example, thesubsystem 2040 may include an infrared device and associated circuitsand components or a Bluetooth™ communication module to provide forcommunication with similarly enabled systems and devices. Subsystem 2040may further include non-cellular communications such as WiFi or WiMAX.

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to elements of the techniques ofthis application. This written description may enable those skilled inthe art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the techniques of thisapplication. The intended scope of the techniques of this applicationthus includes other structures, systems or methods that do not differfrom the techniques of this application as described herein, and furtherincludes other structures, systems or methods with insubstantialdifferences from the techniques of this application as described herein.

The invention claimed is:
 1. A method at a user equipment forregistering with a third network node using an internet protocol (IP)multimedia subsystem (IMS), the method comprising: creating a tunnelbetween the user equipment and a first network node; sending a firstpublic identity associated with the user equipment to the first networknode; receiving configuration information from the first network nodewith a second private user identifier and a second public useridentifier, the second private user identifier and second public useridentifier being associated with a second network node; registering witha third network node using the second private user identifier and thesecond public user identifier; wherein the configuration information isdivided into validity areas, wherein the validity area is defined basedon a Public Land Mobile Network (PLMN) identity or a geographic boundingarea the user equipment falls within, and wherein the user equipmentuses the second private user identifier and second public useridentifier based on the location of the user equipment.
 2. The method ofclaim 1, wherein a certificate is provided in the tunnel.
 3. The methodof claim 2, wherein the certificate is created based on an identifier atthe user equipment.
 4. The method of claim 3, wherein the identifier isone of a device identifier or a private user identifier.
 5. The methodof claim 4, wherein the identifier is stored on a universal integratedcircuit card on the user equipment.
 6. The method of claim 4, whereinthe identifier is stored in a mobile equipment (ME) of the userequipment.
 7. The method of claim 1, wherein the creating uses acertificate requested by the user equipment.
 8. The method of claim 1,wherein the authenticating provides from the user equipment to the firstnetwork node at least one of a device identifier or a network the UE isregistered on.
 9. The method of claim 1, wherein the receivingconfiguration information is subsequent to providing a configurationrequest to the first network node, including a network identifier thatthe user equipment is registered on.
 10. The method of claim 1, whereinthe registering includes receiving challenge vectors for the secondprivate user identifier and second public user identifier.
 11. A userequipment configured for registering with a third network node using aninternet protocol (IP) multimedia subsystem (IMS), the user equipmentcomprising: a processor; and a communications subsystem, wherein theuser equipment is configured to: create a tunnel between the userequipment and a first network node; send a first public identityassociated with the user equipment to the first network node; receiveconfiguration information from the first network node with a secondprivate user identifier and a second public user identifier, the secondprivate user identifier and second public user identifier beingassociated with a second network node; register with a third networknode using the second private user identifier and the second public useridentifier; wherein the configuration information is divided intovalidity areas, wherein the validity area is defined based on a PublicLand Mobile Network (PLMN) identity or a geographic bounding area theuser equipment falls within, and wherein the user equipment uses thesecond private user identifier and second public user identifier basedon the location of the user equipment.
 12. A method at first networknode configured for authentication between a user equipment and a thirdnetwork node using an internet protocol (IP) multimedia subsystem (IMS),the method comprising: establishing a tunnel with the user equipment;sending a first public identity of the user equipment at first networknode; receiving a configuration information message from the userequipment, the configuration information message including a networkidentifier for a network the user equipment is registered on; obtaining,from a second network node, a second private user identifier and secondpublic user identifier; providing configuration information with thesecond private user identifier and second public user identifier to theuser equipment; wherein the configuration information is divided intovalidity areas, wherein the validity area is defined based on a PublicLand Mobile Network (PLMN) identity or a geographic bounding area theuser equipment falls within, and wherein the user equipment uses thesecond private user identifier and second public user identifier basedon the location of the user equipment.
 13. The method of claim 12,wherein the establishing uses a certificate requested by the userequipment.
 14. The method of claim 13, wherein the certificate iscreated based on an identifier at the user equipment.
 15. The method ofclaim 14, wherein the identifier is one of a device identifier or aprivate user identifier from a universal integrated circuit card on theuser equipment.
 16. The method of claim 14, wherein the identifier isstored in a mobile equipment (ME) of the user equipment.
 17. The methodof claim 12, wherein the authenticating includes receiving from the userequipment at the first network node at least one of a device identifieror a network the UE is registered on.
 18. A first network nodeconfigured for authentication between a user equipment and a thirdnetwork node using an internet protocol (IP) multimedia subsystem (IMS)the first network node comprising: a processor; and a communicationssubsystem, wherein the first network node is configured to: establish atunnel with the user equipment; send a first public identity of the userequipment at first network node; receive a configuration informationmessage from the user equipment, the configuration information messageincluding a network identifier for a network the user equipment isregistered on; obtain, from a second network node, a second private useridentifier and second public user identifier; provide configurationinformation with the second private user identifier and second publicuser identifier to the user equipment; wherein the configurationinformation is divided into validity areas, wherein the validity area isdefined based on a Public Land Mobile Network (PLMN) identity or ageographic bounding area the user equipment falls within, and whereinthe user equipment uses the second private user identifier and secondpublic user identifier based on the location of the user equipment.